Have a bunch of referenced DLL’s cluttering up your deployment? Just say no and ILMerge them…

Tuesday, February 24, 2009

Have a bunch of referenced DLL’s cluttering up your deployment? Just say no and ILMerge them…

Daniel Cazzulino's Blog - Leveraging ILMerge to simplify deployment and your users experience

“ILMerge is one of those little-known gems that are an absolute must-have once you know how to apply them effectively to scenarios you didn't even think about.

Specifically, whenever you work on a multi-project solution that may also use external projects in turn, forcing your users to add (say) five assembly references just to your "entry point" library is clearly a bad experience. One example that comes to mind is Enterprise Library, where you add a minimum of 3 (IIRC) assembly references to use just about *any* block in isolation. If you use more than one, it quickly becomes quite a big list. Wouldn't you want to just give your users a single EnterpriseLibrary.dll?

Of course, you wouldn't do it if the price of that end-user simplicity was that you had to merge all your projects into a single one, complicating the dependency management and isolation between layers.

Also, if you use a bunch of external libraries, do you think your users care? Having a single Dll gives a feeling that "this is small, I can manage to take a dependency on this single library".

ILMerge to the rescue

The two scenarios are precisely ILMerge targets. It allows you to merge multiple assemblies into a single one, offering various options when doing so.

…”

Daniel’s post reminded me that it’s been a long time since I’ve posted about ILMerge and that I STILL want to incorporate its usage into my products. I really do like the idea of having a deliverable that’s a single file…

I like the post because he provides some real world samples, includes on MSBuild snips and provides some times on some little things that might come in handy (like the /internalize parameter).