The State of Linkers for .NET apps (aka "Please Sir, May I have a Linker" 2009 edition)
Solution 1:
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:
- A presentation of the linker
- A combined used of the linker and mkbundle
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.
Solution 2:
FWIW
Mono has had a linker for quite a while.
Here is an example of how to use mkbundle.
Solution 3:
http://www.xenocode.com/
This is what we use. So far, after a year or to of somewhat limited use (maybe 500 installations in the wild), zero problems.
And it's pretty reasonably priced. They have some more expensive full virtualization software (that bundles your app with other apps and even an O/S). But we didn't need all of that. Our cost a year or so ago was $400.I think it's a bit more expensive now but much less than Thinstall.
And they have great demos you can download, like IE 8. No install required.
Solution 4:
Client profile registers with Windows, but in a special way since you don't want to confuse a machine with only client profile with a machine with the full .net 3.5
Client profile:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\DotNetClient\v3.5\Install
Full .net 3.5:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5\Install
Solution 5:
This is the main one I heard of a long time ago on .NET Rocks. I never really got a change to try it out though
http://www.remotesoft.com/linker/