Use cases for using netmodules when compiling .NET assemblies?

Question

I'm interested in use cases for netmodules in .NET. In particular, I've been looking into better ways to break up solutions in .NET but not have quite as many assemblies to deploy. Netmodules are a very interesting idea, but they appear to break debugging and are not natively supported in Visual Studio (though they are for MSBuild) . I'd prefer to rely on something native to .NET, so ILMerge, while interesting isn't what I really want.

For some of my own projects, I'm also beginning to use FAKE , which allows for some interesting build steps, such as separating out test files . In other words, writing custom compile steps is not a problem.

Answer 1

A netmodule on its own is practically worthless: Their types and code cannot be loaded and executed by the runtime environment. You can only load types and execute code from assemblies , so it's quite likely that you will eventually combine several netmodules into a (multi-file) assembly. So let's take a look at the benefits of these.

Jeffrey Richter mentions three uses for multi-file assemblies in his book CLR via C# (p. 44), two of which result from the use of netmodules:

1. "You can partition your types among separate files, allowing for files to be incrementally downloaded […]. Partitioning the types into separate files also allows for partial or piecemeal packaging and deployment for applications you purchase and install."

   At least Microsoft's implementation of the CLI (.NET) seems to load multi-file assembly incrementally, and not in its entirety right from the start. A module from an assembly only appears to get loaded from disk (or from the network?) when a type inside it is actually needed.

2. "You can create assemblies consisting of types implemented in different programming languages. […]"

   I'm not certain that this actually adds much value in real-world scenarios, (a) because Visual Studio doesn't support project references to netmodules, and (b) because you can get the same benefit with assemblies.

   There's one notable difference between a multi-assembly and multi-file assembly approach: One assembly cannot by default access another assembly's types that have internal / Friend (ie assembly) visibility. If you were compiling to modules instead and then link them into a single multi-file assembly, a module compiled from C# could access internal types of a module compiled with VB.NET (and vice versa).

   You'll find a brief demonstration of this below.

   ---

   CsharpClass.cs:

    internal class CsharpClass { } 

   VbClass.vb:

    Friend Class VbClass : End Class 

   Program.cs:

    public static class Program { public static void Main() { var vbClass = new VbClass(); var csharpClass = new CsharpClass(); } } 

   Build script for netmodules:

    csc.exe /t:module /out:CsharpClass.netmodule CsharpClass.cs vbc.exe /t:module /out:VbClass.netmodule VbClass.vb csc.exe /t:exe /out:Program.exe /addmodule:CsharpClass.netmodule /addmodule:VbClass.netmodule Program.cs 

   This build will work and execute without any errors.

   Note that there is nothing magical about the .netmodule file extension; this is only a convention, but the output file is a regular .NET DLL.

   Build script for assemblies:

    csc.exe /t:library /out:CsharpClass.dll CsharpClass.cs vbc.exe /t:library /out:VbClass.dll VbClass.vb csc.exe /t:exe /out:Program.exe /r:CsharpClass.dll /r:VbClass.dll Program.cs 

   This build will fail because:

    Program.cs(5,27): error CS0122: 'VbClass' is inaccessible due to its protection level Program.cs(5,23): error CS0143: The type 'VbClass' has no constructors defined Program.cs(6,31): error CS0122: 'CsharpClass' is inaccessible due to its protection level Program.cs(6,27): error CS0143: The type 'CsharpClass' has no constructors defined 

Answer 2

Can you use Jeffrey Richter's assembly embedding technique ? I haven't tried it myself, but it looks promising.

Answer 3

The lack of responses makes me think that the other options noted in the comments and answers are generally considered better approaches than netmodules. By that, I assume that means no one actually uses or knows of any good uses for netmodules.