The State of Linkers for .NET apps (aka “Please Sir, May I have a Linker” 2009 edition)

The case of the Mono Linker.

I can’t talk much about the other pieces of software that are listed here, but as the author of the Mono Linker, I can tell what it does and what it does not.

The Mono Linker is only a managed linker, so by definition, it takes assemblies, and removes what’s not necessary for a program to run. It doesn’t merge assemblies all together, and it doesn’t make a native program out of them.

There’s a Mono.Merge clone of ILMerge, but it’s not complete, and its author is not maintaining it. To generate a native program containing both the Mono runtime and assemblies, Mono provides the mkbundle tool.

Also, as it is only a managed tool, which is altering assemblies, if you give it strong named assemblies, and that you don’t have the private keys to sign them back, you’ll have troubles running those assemblies.

I wrote a couple of blog posts about the linker:

About our experience with the Linker. The Linker is currently used in two parts of the Mono project. It’s used to generate the assembly that we distribute for people to embed our C# compiler, Mono.CSharp.dll. You can watch Miguel’s presentation at the PDC, which describes how we do that. It’s pretty straightforward, and it’s a basic usage of the Linker, which is a customizable tool, and it’s pretty easy to write custom steps for it.

A more complex use of the Linker is the way we create our Moonlight assemblies. Moonlight being our implementation of Silverlight, the assemblies are a subset of the desktop assemblies. So we link our desktop assemblies to reduce their sizes, and using custom steps, we’re transforming the public API to match Silverlight’s.

So yeah, the Linker has some pretty rough edges, such as the command line interface for instance, or the fact that you have to really know what you’re doing, or you may end up with some weird assemblies, but all in all, it works really well for us.

Leave a Comment