Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>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 <em>assemblies</em>, 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.</p> <p>Jeffrey Richter mentions three uses for multi-file assemblies in his book <a href="http://rads.stackoverflow.com/amzn/click/0735627045" rel="nofollow" title="Amazon.com book page">CLR via C#</a> (p. 44), two of which result from the use of netmodules:</p> <ol> <li><blockquote> <p><em>"You can partition your types among separate files, allowing for files to be incrementally downloaded [&hellip;]. Partitioning the types into separate files also allows for partial or piecemeal packaging and deployment for applications you purchase and install."</em></p> </blockquote> <p>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.</p></li> <li><blockquote> <p><em>"You can create assemblies consisting of types implemented in different programming languages. [&hellip;]"</em></p> </blockquote> <p>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.</p> <p>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 <code>internal</code>/<code>Friend</code> (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 <code>internal</code> types of a module compiled with VB.NET (and vice versa).</p> <p>You'll find a brief demonstration of this below.</p> <hr> <p><strong>CsharpClass.cs:</strong></p> <pre class="lang-cs prettyprint-override"><code>internal class CsharpClass { } </code></pre> <p><strong>VbClass.vb:</strong></p> <pre class="lang-vb prettyprint-override"><code>Friend Class VbClass : End Class </code></pre> <p><strong>Program.cs:</strong></p> <pre class="lang-cs prettyprint-override"><code>public static class Program { public static void Main() { var vbClass = new VbClass(); var csharpClass = new CsharpClass(); } } </code></pre> <p><strong>Build script for netmodules:</strong></p> <pre class="lang-none prettyprint-override"><code>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 </code></pre> <p>This build will work and execute without any errors.</p> <p>Note that there is nothing magical about the <code>.netmodule</code> file extension; this is only a convention, but the output file is a regular .NET DLL.</p> <p><strong>Build script for assemblies:</strong></p> <pre class="lang-none prettyprint-override"><code>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 </code></pre> <p>This build will fail because:</p> <pre class="lang-none prettyprint-override"><code>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 </code></pre></li> </ol>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload