.NET Module vs Assembly

Question

I've been trying to wrap my head around the 'right' answer to this? there are a couple of topics on stackoverflow that covers this, but that conflicts somewhat with msdn documentation.

for example, note the diagram in the 2nd answer to his question: What is a Managed Module (compared to an Assembly)?

Now look at the msdn diagram: http://msdn.microsoft.com/en-us/library/zst29sk2(VS.100).aspx

the msdn diagram implies that a single-file assembly does not comprise of a module, but rather of a manifest, il code, type metadata, etc. This is different than many other articles i've read which states that a single file assembly has one module.

What is the answer? If the answer is 'both', then is the module a separate phyical file that is linked via the assembly manifest?

Answer 1

In .net the difference between an assembly and module is that a module does not contain the manifest.

//Copied from CLR via C# 

What is manifest?

The manifest is another set of metadata tables that basically contain the names of the files that are part of the assembly. They also describe the assembly’s version, culture, publisher, publicly exported types, and all of the files that comprise the assembly.

The CLR operates on assemblies; that is, the CLR always loads the file that contains the manifest metadata tables first and then uses the manifest to get the names of the other files/modules that are in the assembly.

How to Combinine Modules to Form an Assembly?

Using C# compiler

To understand how to build a multifile/multimodule assembly, let’s assume that we have two source code files:

■■ RUT.cs, which contains rarely used types

■■ FUT.cs, which contains frequently used types

Let’s compile the rarely used types into their own module so that users of the assembly won’t need to deploy this module if they never access the rarely used types.

csc /t:module RUT.cs 

This line causes the C# compiler to create a RUT.netmodule file. This file is a standard DLL PE file, but, by itself, the CLR can’t load it. Next let’s compile the frequently used types into their own module. We’ll make this module the keeper of the assembly’s manifest because the types are used so often. In fact, because this module will now represent the entire assembly, I’ll change the name of the output file to MultiFileLibrary.dll instead of calling it FUT.dll.

csc /out:MultiFileLibrary.dll /t:library /addmodule:RUT.netmodule FUT.cs 

This line tells the C# compiler to compile the FUT.cs file to produce the MultiFileLibrary.dll file. Because /t:library is specified, a DLL PE file containing the manifest metadata tables is emitted into the MultiFileLibrary.dll file. The /addmodule:RUT.netmodule switch tells the compiler that RUT.netmodule is a file that should be considered part of the assembly. Specifically, the /addmodule switch tells the compiler to add the file to the FileDef manifest metadata table and to add RUT.netmodule’s publicly exported types to the ExportedTypesDef manifest metadata table.

After the compiler has finished all of its processing, the two files shown in Figure 2-1 are created. The module on the right contains the manifest.

Using the Assembly Linker

The AL.exe utility can produce an EXE or a DLL PE file that contains only a manifest describing the types in other modules. To understand how AL.exe works, let’s change the way the MultiFileLibrary.dll assembly is built.

csc /t:module RUT.cs csc /t:module FUT.cs al /out: MultiFileLibrary.dll /t:library FUT.netmodule RUT.netmodule 

Figure 2-3 shows the files that result from executing these statements.

I would suggest you to read CHAPTER 2: Building, Packaging, Deploying, and Administering Applications and Types from CLR via C# by Jeffrey Richter to understand the concept in detail.