Thursday, August 13, 2009

ILMerge (Merging .net assemblies)

In this article, we will be using ILMerge programming interface to merge assemblies.

The first question which comes to our mind is if we have classes with the same name in two assemblies then what would be the behavior of this utility? To answer this question we ask you a question: What do you generally want in such a scenario? You would definitely want to be notified all such cases so that you can make decision on your own as a developer. This is generally the case and this is also the default setting of ILMerge. ILMerge also allows you to explicitly specify the names of classes which you want to allow having duplicates. All other classes will not be allowed to have duplicates.

But sometimes you want to handle these types of cases differently. You want to rename the conflicting names in order to merge the assemblies successfully. This may be true when you want to merge third party assemblies. In this case, you have no access to the source code.

Command line option: [/allowDup[:typeName]]*

If we want to access ILMerge through our code then AllowDuplicateType(string TypeName) is provided for this purpose. Here TypeName is the type we want to handle if a duplicate is found. If we want to rename all duplicates found then pass null as argument.

Now the biggest question in the world is How we can access a particular definition of a class if there are two classes with same names but with different definition?

Classification of Assemblies:
The assemblies, being merged, can be classified into two types.
1. Primary Assembly: The first of the assemblies being merged.
2. Other Assembly: All assembly other than Primary assembly.

Can obfuscated assemblies be merged?
No! Obfuscated assemblies can not be merged.

We can also sign the target assemblies with a key file. All we have to do is to provide the key file. This also supports delay signing.

What if I need to merge the duplicate definitions into a single type? Can I do that?
Sure! There is a switch provided for this requirement in ILMerge. It is "UnionMerge". This can be used if duplicates are not allowed already using allowDup switch. This options is turned off by default. It would copy the members from all the source assemblies and would result in a new definition in target assembly. Now the question is what if they have same methods with same signatures. We all know that we are not allowed to overload methods with same signatures. Would it generates some errors?

We all know that assemblies can be created as application executables (*.exe) or Dynamic Link Library (DLL). We can specify how we want to create target assembly. I mean whether we want it to be created as Win / Console executable or a dll. By default, the type of target assembly matches with that of Primary assembly. "TargetKind" switch is provided to define the type of the target assembly.

We might have our assemblies in frameworks other than the desired framework of our target assembly. Cuurrently, only 1.0, 1.1 and 2.0 frameworks are supported for the target assembly. To specify a particular framework, we also need to specify the directory in which mscorlib.dll resides for the particular framework. Yes you are right! We can not create target assemblies conforming to 3.0 / 3.5 frameworks.

ILMerge also allows to modify the accessibility (setting as Private) of object types in assemblies other than Primary assembly. During this, it allows to specify the list of exclusions in the form of a file. In this file exclusions are specified in the form of regular expression.

PEVERIFY is part of .net SDK tool. This can be used to verify that the output of ILMerge will be loaded in a .net runtime successfully.

No comments: