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.

@chibacity: How about the fact that its horrible fickle, especially with regard to merged 3rd party assemblies, which have already been ilmerged. Also, scarcely-documented, cryptic error messages are no fun. — pblasucci, Aug 02 '10 at 13:33
@pblasucci "horrible fickle" I guess I must have had a much better experience with it. — Tim Lloyd, Aug 02 '10 at 13:42
@pblasucci Your reaction got me thinking. A big thing I had overlooked is that yes, the CLI is tricky, but I gave up on that a long time ago. I have always used the following GUI tool that uses ILMerge under the covers: http://www.genetibase.com/cforce/nugenunify.php. — Tim Lloyd, Aug 02 '10 at 14:15
@chibacity: I don't have anything against ILMerge. However, some of the guys at my company don't like/want it. It's also one extra tool in the stack when .NET appears to have an existing alternative. — , Aug 02 '10 at 15:54
@user442859 I recently saw that, too. Thanks for pointing it out. — , Sep 21 '10 at 18:15
"horrible, fickle, guys at my company don't want it, it's an extra tool" ... So we've heard some emotional and irrational reasons for not wanting to use ILMerge - are there any good ones? — PandaWood, Dec 22 '10 at 10:19

stakx - no longer contributing · Answer 1 · 2012-08-22T16:17:09.320

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:

"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.
"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 (i.e. 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
```

score 1 · Answer 2 · answered Mar 13 '11 at 16:30

1

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

answered Mar 13 '11 at 16:30

Patrick Szalapski

8,738
11
67
129

That's an interesting technique. However, my question was really more to identify uses for netmodules. – Mar 14 '11 at 04:09

score 0 · Accepted Answer · answered Mar 14 '11 at 04:10

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.

Use cases for using netmodules when compiling .NET assemblies?

3 Answers3