Multimodule Assemblies

for RuBoard

An assembly can be made up of multiple modules. A module is a DLL (or EXE) that contains managed code plus metadata, but not necessarily a manifest. However, an assembly must have one and only one manifest. Hence an assembly can contain multiple modules, but only one of them can have a manifest that provides information on the contents of all the modules in the assembly. The module with the manifest may have just the manifest, or it can contain other code or resources.

The main advantage of breaking an assembly into multiple modules is that each module is contained in a separate DLL file. This allows Web downloads to be performed on demand, on a per-module basis. This can improve performance and memory consumption. Even in a local scenario, the CLR loads classes on the local machine with module granularity, which can improve efficiency. Another reason for constructing an assembly with multiple modules is that you may have written each part of an assembly in a different .NET language. To build an assembly that contains multiple modules, you need to build each module separately, and then combine them with the Al.exe utility.

There are two ways to go about creating a multimodule assembly. One way is to create all the modules without any manifest, and then create one additional module that contains only a manifest for the entire assembly, but no actual code. The other technique is to have just one module in the assembly that contains both code and a manifest for the entire assembly, and to have all other modules in the assembly contain only code, with no manifest. We will describe the first alternative, since it is more symmetric and easier to visualize. The second alternative is not described here, however, it is done in a similar way, with the same tools.

Visual Studio.NET does not allow you to do this for C# projects. The MultiModule example illustrates the mechanics of how to create a multiple-module assembly. The example directory contains three files. Add.cs and Sub.cs will be built into separate modules and then combined together in an assembly. Compute.cs uses this assembly. Add.cs has one class with one method; Add . Sub.cs has another class that has one method, Sub .

 public class MyCalc  {        public int Add(int a, int b)        {              return a + b;        }  }  public class MyCalcSub  {        public int Sub(int a, int b)        {              return a - b;        }  } 

We create two modules with no assembly manifest by running build.bat , which has two commands:

 csc /target:module /out:add.dll add.cs  csc /target:module /out:sub.dll sub.cs 

If you look at add.dll in ILDASM, you will see that there is a .module add.dll statement but no .assembly statement. We now can build an assembly with a manifest using the Assembly Linker tool Al.exe by running link.bat , which has one command:

 Al add.dll, sub.dll /out:arith.dll 

As Figure 7-11 shows, arith.dll contains only a manifest. The manifest shows that the assembly is made up of two separate, distinct files, and the types in those files are listed in the manifest.

Figure 7-11. Manifest for a multimodule assembly.

We have a simple client program, compute.cs , that uses the types in arith.dll .

 public class Compute  {        public static void Main(string[] args)        {              MyCalc x = new MyCalc();              int y = x.Add(1, 3);              Console.WriteLine("y = " + y.ToString());              MyCalcSub z = new MyCalcSub();              y = z.Sub(1, 3);              Console.WriteLine("y = " + y.ToString());              return;        }  } 

We can build it with the command:

 csc /r:arith.dll compute.cs 

This will produce compute.exe, which we can run.

for RuBoard