Next let's look at another method of creating a multifile assembly. Both the VB.NET Compiler and the C# Compiler support an /addmodule switch that allows you to automatically link modules into the assembly that you are building with the compiler executive. I have done this in my example in the BuildWithCSC.bat (Figure 4).
The first part of the batch file is the exact same as in the first option, setting the path and building the VB.NET module. The difference is that instead of building the C# project as a module (as in Figure 3), we build it as an assembly, linking the VB.NET module to it (see Figure 5). First, we change the /t[arget] option to specify that we want to build a code library instead of a module (Figure 5, Line 3), as we did previously. Next, we use the /addmodule switch to add the VBLibrary.netmodule (Figure 5, Line 5), and last, we specify our assembly name (MultifileAssembly.dll) instead of CSLibrary.netmodule, as we did previously.
The net result of this is that we end up with only two files in our assembly, VBLibrary.netmodule and MultifileAssembly.dll, instead of the three we had previoiusly. And now, instead of having an assembly file with only the assembly manifest, we now have the assembly manifest built into the same file with the C# project code. This method might be preferred in situation where speed of deployment is less of an issue and having fewer files is more important. Ultimately, the CLR does not care which method you choose because both will act like one assemly as far as it is concerned, and the same goes for VB.NET and C# compilers (and likely most other compilers).