Using ILMerge Internalization with Caution

| by Abel Avram Follow 11 Followers on Aug 03, 2010. Estimated reading time: 2 minutes |

ILMerge is a .NET utility that can merge multiple assemblies into one, and can change the visibility of types from public to internal. This can have positive or negative results depending on how the resulting assembly is going to be used.

ILMerge can be useful if someone creates a framework or an application and wants to bundle it with all the frameworks or libraries it depends upon, possibly hiding the later from the user, and making the resulting framework easier to be installed and used. ILMerge can be used from the command prompt or programmatically. One of the setable properties is Internalize which can be used to hide types by making them internal.

Udi Dahan, a Microsoft Solutions Architect MVP and father of NServiceBus, has used ILMerge to bundle all NServiceBus’ dependencies into on assembly in version 1.9, but he didn’t internalize any type resulting in:

all the 3rd party types being exposed when a developer used NServiceBus. For those who happened to use the same version of those libraries as that which was merged, it wasn’t a problem. Unfortunately, developers who used libraries like Castle tended to be very particular about which version they used – which resulted in version conflicts, also known as “versioning hell”.

With NServiceBus 2.0, Dahan started using the Internalize feature, but he mentions that not all types should be internalized:

For example, NServiceBus internally uses NHibernate to persist the state of long-running processes (called sagas) and we want this implementation detail to not conflict with anything that developers want to do on top of NServiceBus. The only thing is that for NHibernate to work, it needs certain types to be exposed to the configuration environment, specifically all the types in the NHibernate.Cfg.MappingSchema namespace.

Some users might want to access the API of bundled libraries, but they won’t be able to do it if they are all made internal. So, for some it is better to leave the types as they are. A possible solution is what NServiceBus does, having two builds: one for the general user who just wants to use the framework, and another build, containing the core binaries, for those who want to have full control over it.

ILMerge requires .NET Framework 2.0 or later, and it can merge all .NET assemblies including those generated with .NET 1.0/1.1. The tool works only on Windows, and it is not supporting Rotor or Mono.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread


Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you