8

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

Rory Becker
  • 15,551
  • 16
  • 69
  • 94
  • Rather than having a .bat script, one thing you could do is create a third project (type ClassLibrary will work) whose dependencies are ConsoleApp and ClassLibrary; call it PostSolutionBuildEvents. Then have its post-build be an ILMerge command. This way, you get access to all the macros like `$(SolutionDir)`. – Sarah Vessels Jun 17 '10 at 20:43
  • 1
    Note: You should not need to GAC stuff for this purpose, there are a huge amount of options ranging from "it just works" when nothing is GACd to application config files – Sam Saffron Jun 17 '10 at 21:56
  • 1
    did you ever solve this? same problem here... – Andrew Bullock Dec 15 '11 at 15:20

5 Answers5

5

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 another 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.

Manfred Radlwimmer
  • 13,257
  • 13
  • 53
  • 62
  • 1
    +1 for a response from ILMerge's author! The resultant .pdb file is working fine for me, if it's in the same directory as the merged assembly (exe in my case). See similar question/answers http://stackoverflow.com/questions/1439721/is-there-a-way-to-merge-pdb-files-with-ilmerge – joelsand Jul 17 '13 at 18:18
  • It worked because you did not rename stuff (see my answer). – Eugene Ryabtsev Aug 06 '15 at 07:48
  • @MikeBarnett Just a note. If the out exe has the same name and location (essentially the output is overwriting the original exe and pdb), the application appears to crash on startup. eg `ilmerge /out:foo.exe foo.exe B.dll`. The solution is to put the exe and matching pdb in a different directory `ilmerge /out:foo.exe unmerged\foo.exe B.dll`. Interestingly this doesn't appear to be a problem with the `/ndebug` switch, or the pdb file is missing. – GP89 Sep 05 '18 at 15:53
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.

Mike Atlas
  • 8,193
  • 4
  • 46
  • 62
  • I have added to my original question explaining (kind of) why I would like to do this. – Rory Becker Jun 17 '10 at 21:48
  • Regarding your update, I think you're making more problems then you're solving by trying to go this route. Start a new question using your update as the question - there is definitely a better solution than the approach you're trying. – Mike Atlas Jun 17 '10 at 23:18
  • I'm not sure I understand... What are you suggesting I ask? – Rory Becker Jun 18 '10 at 08:44
  • Describe what you're trying to solve (multiple assemblies with the same name but different versions, in the same directory) and ask if anyone has a better solution than abusing ILMerge. – Mike Atlas Jun 18 '10 at 15:36
  • The benefit I'm getting is understanding why there is a Castle Windsor registration issue if I ILMerge but not if I don't. – jnm2 Feb 10 '17 at 19:46
0

I tried to do something like this and found that you should not rename anything, neither before not after the merge. Moving stuff to to separate directory is fine. If you do not rename anything, it works.

Eugene Ryabtsev
  • 2,232
  • 1
  • 23
  • 37
0

If you are still using ILMerge, like I am, there is also an another solution to debugging issues. At least for me the dubugging started working after NOT using the portable PDB format. My project is .NET Standard 2.0 and I was running it under .NET Framework.

Ollikat
  • 81
  • 6
-1

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.

Miha Markic
  • 3,158
  • 22
  • 28