How do I debug into an ILMerged assembly?

Question

Summary

I want to alter the build process of a 2-assembly solution, such that a call to ILMerge is invoked, and the build results in a single assembly. Further I would like to be able to debug into the resultant assembly.

Preparation - A simple example

1. New Solution - ClassLibrary1
2. Create a static function 'GetMessage' in Class1 which returns the string "Hello world"
3. Create new console app which references the ClassLibrary.
4. Output GetMessage from main() via the console.

You now have a 2 assembly app which outputs "Hello World" to the console.

So what next..?

I would like to alter the Console app build process, to include a post build step which uses ILMerge, to merge the ClassLibrary assembly into the Console assembly

After this step I should be able to:

• Run the Console app directly with no ClassLibrary1.dll present
• Run the Console app via F5 (or F11) in VS and be able to debug into each of the 2 projects.

Limited Success

I read this blogpost and managed to achieve the merge I was after with a post-build command of...

"$(ProjectDir)ILMerge.bat" "$(TargetDir)" $(ProjectName)

...and an ILMerge.bat file which read...

CD %1
Copy %2.exe temp.exe
ILMerge.exe /out:%2.exe temp.exe ClassLibrary1.dll 
Del temp.exe
Del ClassLibrary1.*

This works fairly well, and does in fact produce an exe which runs outside the VS environment as required. However it does not appear to produce symbols (.pdb file) which VS is able to use in order to debug into the code.

I think this is the last piece of the puzzle.

Does anyone know how I can make this work?

FWIW I am running VS2010 on an x64 Win7 x64 machine.

Update: Why do I want to do this?

It's been asked: 'Do I really need to ILMerge during the debug scenario?'

The assemblies of my solution will need to coexist in the same folder as those of other solutions (some of which I will likely develop)

Some of these solutions will share dependencies on different versions of some assemblies.

So Solution1 might be made up of Console1 and ClassLibrary1.dll(v1) and Solution2 might be made up of Console2 and Classlibrary1.dll(v2).

Rather than register everything in the GAC, I thought I could ILMerge the correct version of a dependency into the primary assembly of the solution to avoid a collision.

However this currently renders it impossible to debug the solution, which I need to do in place in conjunction with the other solutions which will be present.

Does this sound complicated? That's because it is.. :D

Answer 1

I would suggest that you only ILMerge release builds of your assemblies. I can't imagine any benefit you'd get from merging debug assemblies.

Answer 2

I don't think ILMerge can do it. OTOH smartassembly from red-gate (not free) can do it, at least so it says at features

And yes, I do agree with Mike to only use ILMerge for release versions.

Answer 3

I think this is answered here: http://stackoverflow.com/questions/1439721/is-there-a-way-to-merge-pdb-files-with-ilmerge

Once the PDBs are merged you should be able to debug

Answer 4

I'm sorry you're having problems. I didn't follow your exact steps, but I created a console application, A.exe, that called a method in a dll, B.dll. I built both assemblies in Debug mode (so that they had PDB files). I then merged them like this:

ilmerge /out:foo.exe A.exe B.dll

(Actually A and B were in anothr directory so my command line was a little more complicated, but that shouldn't make a difference.) After ILMerge completed, there were two files in the current directory: foo.exe and foo.pdb. I then typed:

devenv foo.exe

This opened up Visual Studio and then I hit "F10" to start the debugger. I was able to step into the Main method in the executable and then used "F11" to step into the method in that had originally been in B.dll. The debugging experience was just the same as it had been in the original Visual Studio solution with the two assemblies.

If you are still having problems, please feel free to put your entire solution into a zip file and send it to me (mbarnett at microsoft dot com) and I can try it out.