4

First of all, I'm not sure if this is a problem with ILMerge or not, but I can't merge.dll files into my application. I tried this on the command line:

ilmerge /target:winexe /out:test.exe MyApp.exe lib1.dll lib2.dll lib3.dll

I got the following error, and I have no idea what it means:

There were errors reported in MyApp's metadata. The pdb associated with D:\C#\source\bin\ReleaseMyApp.exe is out of date.

I'm using the latest version by the way (2.10.526.0), but yeah I can't get this to work and I really need some help. What does the above error mean and how can I fix it?

John Saunders
  • 160,644
  • 26
  • 247
  • 397
Iceyoshi
  • 623
  • 3
  • 10
  • 14
  • Are there actually PDB files? How about compiling to Release version and removing any PDBs before calling `ilmerge`? – Uwe Keim Jan 08 '11 at 19:44
  • 3
    For ILMerge, I use it like `ilmerge /ndebug /target:winexe /out:test.exe app.exe lib1.dll lib2.dll`. – Uwe Keim Jan 08 '11 at 20:01

3 Answers3

5

The pdb associated with D:\C#\source\bin\ReleaseMyApp.exe is out of date.

Since you haven't explicitly said that you have checked the pdb and exes are in sync, I guess I'll ask the obvious question - Is there a pdb in the folder and have you checked the timestamps on the files?

As I understand it, if there is debug info available for the source files, then ilmerge will create debug information for the target and if the original is out-of-date, then it probably displays this error rather than generate incorrect information.

If you don't need the debug information, what happens if you delete the pdb files?

sgmoore
  • 15,694
  • 5
  • 43
  • 67
  • The pdb files were up to date, I just copied them after build suceeded. Also when I deleted it it seemed to work, although not surprising I received another error, fantastic. "Unresolved assembly reference not allowed: Microsoft.mshtml..." So after a bit of googling, I realized you need to specify the path to the .NET Framework version 4. So I did this: ilmerge /targetplatform:v4,C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319 /out:test.exe MyApp.exe lib1.dll lib2.dll lib3.dll I would expect it to work, but nope, I still get the same error. – Iceyoshi Jan 08 '11 at 20:27
  • Did you try using the config file to force ilmerge to run using Framework 4? See http://research.microsoft.com/en-us/people/mbarnett/ilmerge-40-exe-config.aspx – sgmoore Jan 10 '11 at 14:58
0

I expect this type metadata is being stored as a string, perhaps in explicit code, but perhaps via a "typeof" in an attribute.

You might try handling the AppDomain's TypeResolve event, detecting the type string that is failing and returning the Type you intend - this should work around the fact that it is now in a different assembly.

http://msdn.microsoft.com/en-us/library/system.appdomain.typeresolve.aspx

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
0

Would it help to try .NETZ instead of ILMerge?

Uwe Keim
  • 39,551
  • 56
  • 175
  • 291
  • 1
    Nope, because I tried that program and of course, it doesn't work. I used: netz -s app.exe lib1.dll lib2.dll as per the usage, but I get some huge error when I open the packed .exe. Removing the -s didn't do anything. Not sure if I used it right, what is the proper syntax to use on the command-line? – Iceyoshi Jan 08 '11 at 19:55
  • I use it like `netz -s -z -w app.exe lib1.dll lib2.dll -so` – Uwe Keim Jan 08 '11 at 19:59
  • I just tried the above syntax and I got 2 warnings: ! Warning: 1001 Cannot process assembly metadata! ! Warning: 1005 Cannot process assembly license information! Apart from that, I think everything went fine but launching the packed .exe doesn't work and shows some exception in a MessageBox. – Iceyoshi Jan 08 '11 at 20:31