Netmodule vs. Assembly

In .Net framework Assembly is the minimum unit of deployment. You cannot deploy anything less than an assembly. To CLR, a type does not exist outside of the context of an assembly.

 

Assembly can contain one or more files. The files can be any physical files. They can be a resource file, a netmodule, or native dlls.

 

An assembly always contains an assembly manifest. Assembly manifest is the metadata of an assembly. It contains assembly definition identity, files in the assembly, type reference information, referenced assemblies, among other things.

 

Netmodule is a unit of compilation.  A compiler may give the option to compile a collection of source files into an assembly, or a netmodule. Netmodule contains type metadata and compiled code. It does not contain an assembly manifest.

 

A netmodule can not be deployed alone. It has to be linked into an assembly. This can be done by using compiler’s /addmodule switch (if the compiler supports it), al.exe, or in .Net framework 2.0, link.exe. After linking, the netmodule can be deployed with the assembly. The .Net framework 2.0 link.exe can produce a single file assembly, while all the other approaches produce multi-file assemblies.

 

Given a collection of source files, when do you want to compile them into netmodule instead of assembly?

 

This can happen for many reasons.

 

First, Multi-language assemblies.

 

If the assembly is consist of source files with different programming languages, you have to compile files with the same programming languages into netmodules, then link them into assemblies. (.Net framework 2.0 link.exe can link multiple netmodules into a single file assembly. But it still requires the inputs as netmodules).

 

Second, Separately maintained source files.

 

If the assembly is maintained by multiple developers, it may make sense to separate the source files into small collections. Each collection is owned by an individual developer. Collections are compiled as netmodules, then linked to the final assembly.

 

Third, Small download footprint.

 

As explained in my MultiModule Assembly post, if the assembly is hosted in an http site, CLR will only download the main module at the first time. The remaining modules will be downloaded on demand. You can separate the less frequently used code from the main line code, and compiled the less frequently used code as a netmodule. User will only download the netmodule when it is needed.

 

Fourth, link the same source files into multiple assemblies.

 

You may have some common code that is used in multiple assemblies. The common code is small enough that it is not worth to compile them into a separate assembly. To avoid compiling the same source files multiple times, you can compile them into a netmodule, then link it into different assemblies.

 

You have to be very careful using this technique though. Since the code is statically included in all the assemblies, if you service the code, you will have to distribute a new version for every assembly. For this reason, if ever possible, you should look to ship the common code in a separate assembly.

 

I am sure readers will have more scenarios other than the discussed above.