| 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 those modules 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 multi-module 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 have all other modules in the assembly contain only code, with no manifest. We will describe the first of these two alternatives.  | The MultiModule example illustrates the mechanics of how to create a multiple module assembly. The example directory contains the files Add.vb and Sub.vb , which will be built into separate modules and then combined together into an assembly named Arith .dll . Compute.vb uses this assembly. Add.vb has one class with one method, Add . Sub.vb has another class that has one method, Subtract . | 'Add.vb Imports System Public Class MyCalcAdd Public Function Add(_ a as Integer, b as Integer) as Integer return a + b End Function End Class 'Sub.vb Imports System Public Class MyCalcSub Public Function Subtract(_ a as Integer, b as Integer) as Integer return a - b End Function End Class We create two modules with no assembly manifest by running build.bat , which has two commands: Rem Build.bat vbc /target:module /out:add.dll add.vb vbc /target:module /out:sub.dll sub.vb 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: Rem Link.bat Al add.dll, sub.dll /out:arith.dll The arith.dll assembly only contains a manifest, with no actual code. Figure 9-20 shows that the manifest is made up of two separate, distinct files ( add.dll and sub.dll ), and the types in those files are also listed in the manifest. Figure 9-20. Manifest for a multi-module Assembly.  We have a simple client program, compute.vb , that uses the types in arith.dll . 'Compute.vb Imports System Public Class Compute Public Shared Sub Main() Dim mca as MyCalcAdd = new MyCalcAdd() Dim y as Integer = mca.Add(1, 3) Console.WriteLine("y = " + y.ToString()) Dim mcs as MyCalcSub = new MyCalcSub() y = mcs.Subtract(1, 3) Console.WriteLine("y = " + y.ToString()) End Sub End Class We can build it with the command vbc /r:arith.dll compute.vb This will produce compute.exe , which we can run.  | 
