From the ILMerge homepage at MS Research:
A Great Alternative to using ILMerge
If you cannot use ILMerge because you are trying to merge WPF assemblies, then here is a great way for you to get the same effect, courtesy of Jeffrey Richter: embed the dlls you want to merge as resources and load them on demand! In many ways, this is a better technique than using ILMerge, so I strongly urge you to check it out, even if ILMerge is working for your scenario.
The alternative solution is part of Jeffrey Richter's book CLR via C# CLR via C#, Third Edition (Microsoft Press, 2010; ISBN: 9780735627048), you can read about it there:
How does it work?
It adds the required .DLLs as embedded resources to the primary .EXE file and uses AppDomain.AssemblyResolve to return the assemblies.
This is what Mike Barnett (the creator of ILMerge) says about it:
As the author of ILMerge, I think this is fantastic! If I had known about this, I never would have written ILMerge.
Many people have run into problems using ILMerge for WPF applications because WPF encodes assembly identities in binary resources that ILMerge is unable to modify. But this should work great for them.
1 comment:
But doesn't that method lose the potentially big optimization benefit of ILMerge?
I have some .dll's that are low-level computational libraries where if the calls are run back to back and inlined, then the JIT can make some significant optimizations speeding things up. My understanding is that inlining won't happen if those calls are across .dll's, even if those .dll's are loaded from the same file. But if ILMerge merges them into one assembly, then the JIT compiler will do that inlining.
Is that not true?
Post a Comment