As you know, traditional linking of object code is no longer necessary in .NET. A .NET program will usually consist of multiple parts. A typical .NET application consists of an executable assembly, a few assemblies in the program directory, and a few assemblies in the global assembly cache. When the program is run, the runtime combines all these parts to a program. Linking at compile time is no longer necessary.
But sometimes, it is nevertheless useful to combine all parts a program needs to execute into a single assembly. For example, you might want to simplify the deployment of your application by combining the program, all required libraries, and all resources, into a single .exe file.
If all parts of your program are written by yourself in the same language, you can obviously just add all source files to a single project. The result will be a single DLL or EXE containing all dependencies.
csc /target:winexe /out:Program.exe
MainProgram.cs ClassLibrary1.cs ClassLibrary2.cs
However, if your program is written in multiple languages or if you are using binary third party libraries, you are out of luck.
The .NET compilers already contain options for exactly this. If you compile a project, there is an option to create a module, which is similar to an assembly but without a manifest file. You can then use the al.exe tool to combine some of these modules to a single assembly. This feature makes it possible to create a single assembly that contains multiple languages.
First, you would compile the program and the class libraries to netmodules using the module target. Then you can use the assembly linker al.exe to combine these modules to a single assembly.
csc /target:module /out:ClassLibrary1.netmodule ClassLibrary1.cs
vbc /target:module /out:ClassLibrary2.netmodule ClassLibrary2.vb
vbc /target:module /out:Program.netmodule Program.vb
al /target:winexe /out:Program.exe ClassLibrary1.netmodule
ClassLibrary2.netmodule Program.netmodule
But unfortunately, this method only works if you have all the required parts of your program either as source code or as .NET modules. If you are useing a third party class library in assembly form, you are again out of luck.
Since a .NET module is basically just an assembly without an assembly manifest, it should be possible to convert an assembly to a .NET module, at least that is what I thought. When researching this on Google, I found a tremendously useful tool on Microsoft research called ILMerge. This little gem makes it possible to link multiple assemblies to a single one.
First, you would compile your libraries to DLLs and your program to an EXE referencing the DLLs. This is exactly what Visual Studio would do if you had multiple libraries and a program referencing these libraries, so there is no need to do this on the command line.
csc /target:library /out:ClassLibrary1.dll ClassLibrary1.cs
vbc /target:library /out:ClassLibrary2.dll ClassLibrary2.vb
vbc /target:winexe /out:Program.exe
/reference:ClassLibrary1.dll,ClassLibrary2.dll Program.vb
This will produce a normal .exe that requires the two DLLs in the program directory or in the global assembly cache to run.
Now you can link these parts to a single self-contained EXE, using ILMerge:
ilmerge /target:winexe /out:SelfContainedProgram.exe
Program.exe ClassLibrary1.dll ClassLibrary2.dll
The nice thing about this is that you can also merge third party assemblies like commercial class libraries into your program. And you do not have to modify your build process. All you have to do is to merge the assemblies to a single EXE before deploying.
I found ILMerge tremendously useful, and I think that something like this should be a part of the .NET framework SDK. Maybe just enhance al.exe so that it can also link DLLs.
I have only scratched the surface of the .NET build process and the capabilities of ILMerge, and this article might contain many inaccuracies or even errors. But I found ilmerge.exe so useful that I just had to write about it.
| You must Sign In to use this message board. | |||||
|
|||||
|
|||||
