A Few Concerns

Any time you create a tool that can do something the original development environment can't do, you invite someone to find ways to use it incorrectly or with dubious intent. For such a simple utility, ILMerge can have amazingly complex results. The issue that I expect many developers will encounter is an application that stops working for apparently no reason. You must design the assemblies you plan to merge to work together. Even though this seems obvious, someone will try to merge an updated DLL with an existing EXE and find the two don't work as expected.

The nefarious cracker is perhaps the biggest concern. Someone could create a new merge of your application that contains a virus or other nasty code and attempt to blame it on you (quite successfully, in all probability). You can overcome this particular issue by ensuring you give your application a strong name.

The ILMerge utility output works on all Windows 2000, Windows XP, and Windows 2003 systems. However, it won't work in situations that require use of Mono, an open source implementation of the .NET Framework.

Note: Many developers are under the false assumption that Mono is only for Unix and Linux systems. However, products such as Mainsoft's Visual MainWin also rely on the Mono library. Visual MainWin is a Windows product that lets .NET and Java developers work together on projects. For more information on Visual MainWin see my article, Visual MainWin Crosses the .NET-Java Divide.

Interestingly enough, ILMerge also doesn't work with Rotor, the shared source version of the .NET Framework that Microsoft promotes. Rotor is also the version of the .NET Framework that the European Computer Manufacturer's Association (ECMA) used for its approval process. You'll find Rotor in use on FreeBSD and Macintosh systems, as well as Windows.

Using unmanaged code within your application can also cause problems. For example, if you use PInvoke to locate the security identifier for a user, the resulting code will cause problems in the merged application, because you'll need to use pointers to perform the task. Needless to say, C# code that relies on unsafe pointers won't merge properly.

To be sure that the resulting merged application will work, check the merged application using Portable Executable Verify (PEVerify). Simply type PEVerify and the name of the application at the command prompt and press Enter. The presence of any error messages in the output tells you that the application didn't merge correctly.

Using PEVerify doesn't ensure your code will work, however; it only verifies that the code will load. You still have to test the resulting application to ensure it works as anticipated. Note that PEVerify includes a number of command-line switches you might want to employ when working with large applications. For example, you can use the /BREAK switch to set the maximum number of errors that PEVerify reports. Use the /UNIQUE switch to exclude repetitive errors. I would recommend against using the /IL (verify only the PE structure and the IL structure) and /MD (verify only the PE structure and metadata) switches when using ILMerge because PEVerify could hide some problems you need to know about.

Still, ILMerge is a simple idea that can have dramatic effects in your application development efforts. The authors of this console application have put together a great tool that performs a simple task very well. If you don't want to use a console interface, you can even use ILMerge to build your own GUI-based tool instead. The results of using this tool include less complex application installation, smaller chances for application failure due to lost or mangled support assemblies, slightly smaller assemblies, and even a bit of a performance boost.