Software for bundling .NET assemblies in a single assembly

Question

Say I have a .NET/CLR program Hello.exe (or a DLL Hello.dll) that depends on various third-party .NET DLLs. I want to ship a single file, without providing an actual "installer", so I am looking for some software that can pack all of the dependencies into the executable, then load them before any of my code starts to run.

I also need it to unconditionally load every DLL that is supplied, not only "on-demand", because some of the types in the DLLs are accessed via reflection and so the class loader will never attempt to explicitly load the DLL and thus call the class loader hook. I don't want to have to add code to my executable if it's possible to do this without any of my own code.

I am using SharpDevelop and .NET Framework 4.0 Full Profile, but the ideal solution to this problem will be IDE-agnostic, and work with .NET 3.0 or later (2.0 would be even better, but let's not get greedy...)

Answer 1

How about ILMerge? Its been around for a long time and there's lot of resources. For example, here is a quick intro. Also stackoverflow questions have already covered some common pitfalls, like Merging DLL with EXE.

It is also independent from your build environment. You just need to embed it into your build process.

ILMerge sadly is not perfect. For example, it does not support merging of WPF assemblies. The alternative is to embed the libraries as resources and dynamically load them. For example see this blog post. LibZ Container which allquixotic mentioned is basically doing that.

To LibZ container, there is another alternative, one that is tried and I would give serious thought: Fody.Costura

Mono mkbundle might be yet another alternative, please note however that it produces native code. Dependencies can be statically linked. On Windows, it also requires cygwin to be able to run (also see this forum thread)

Answer 2

LibZ Container instruments your main assembly with code that unpacks zipped assembly resources from the resource file, and loads them from memory. It claims to work with reflection code as well as strong names, and it doesn't modify the original assembly files in any way, so strong-named references will work fine.

Answer 3

il-repack partially satisfies the criteria of the answer, but it unfortunately re-packs the assemblies, which breaks their strong name, so if you depend on assemblies signed with a strong name, this won't work. It also doesn't work with most reflection code until after the assemblies have been class-loaded.