Assemblys vs. Modules ?

[Guest]

Hello,

I’m in the process of reading "Inside Microsft .NET IL Assembler" by Serge
Lidin to gain a better understanding of my .NET code at a lower (IL) level.
There is one concept that I am having trouble grasping, however: Assemblies
versus modules and how they relate to one another. From what I can tell,
assemblies contain one or multiple modules, but I’m not sure of this. I know
that your .NET compiled code can end up in a DLL or an EXE file. Is it a fair
statement that the DLL or EXE file is the actual assembly? I ask this because
of the following statement from the text:

“An assembly is basically a deployment unit, a building block of a managed
application. Assemblies are reusable, allowing different applications to use
the same assembly.â€

In my mind, a deployment unit is a file. Please correct me if I’m wrong here.

Another statement that I could use clarification on:

“Managed .NET applications are called assemblies.. The managed executables
are referred to as modules. You can create single-module assemblies and
multimodule assemblies. As illustrated in Figure 1-1, each assembly contains
one prime module, which carries the assembly identity information in its
metadata.â€

“Applications†are assemblies? What exactly is an application? Is it code
that can be executed? Is it the actual file?

And “managed executables†are modules? Again, is this executable an actual
..exe file?

Lastly, under the description of “Module Metadata Table and Declaration:â€
"Name (offset in the #Strings stream) The module name, which is the same as
the name of the executable file with its extension but without a path. The
length should not exceed 512 characters, counting the zero terminator."

So, the module name has the same name as the executable file. Are they
therefore analogus? If so, does the assembly somehow supersede the entire
file? Any clarification would be much appreciated. Thank you very much...

-Ben

 

[Philip Hristov]

Ben,

Yes, .exe's and .dll's are assemblies. You first create modules - one
or more, which you can build to assemblies (.exe or .dll).

Application - is a set of .exe's (one or more) and .dlls (you may have
single .exe too) which solves specific problem

Module <> .exe. Module is called where you write you source code, when
is compiled, the resulting file is .exe or .dll.

Regards,

Philip.

 

[Jon Skeet [C# MVP]]

Yes, .exe's and .dll's are assemblies. You first create modules - one
or more, which you can build to assemblies (.exe or .dll).

Application - is a set of .exe's (one or more) and .dlls (you may have
single .exe too) which solves specific problem

Module <> .exe. Module is called where you write you source code, when
is compiled, the resulting file is .exe or .dll.

I'm not sure I quite agree with you - you seem to be regarding a module
as a source level object, rather than a compiled object. In .NET
terminology a module is one part (possibly the only part) of an
assembly - in compiled form.

From the docs for the Module class:

<quote>
A module is a portable executable file of type .dll or .exe consisting
of one or more classes and interfaces. There may be multiple namespaces
contained in a single module, and a namespace may span multiple
modules.

One or more modules deployed as a unit compose an assembly.
</quote>

and from partition I of the CLI spec:

<quote>
A module is a single file containing executable content in the format
specified in Partition II.
</quote>

This isn't the same thing as a VB.NET Module, just to throw a further
spanner in the works.

 

[Philip Hristov]

Jon,

I thought that is a VB module.

Regards,

Philip.

 

[Guest]

Hi Jon,

Thanks for your answer. I could use a bit more clarification, though. From
what I can tell, there is reallyi no difference between a module and an
assembly except an assembly has a manifest as well. Is this correct? If so, I
would assume that the assembly linker tool al.exe would simply add a manifest
to a module to produce an assembly. In my experimentation this was not the
case, though.

I first compiled a .cs file to a .exe with csc. Everything worked fine.

Next, for comparison, I compiled the .cs file with .csc but set the target
to module, and got test.netmodule. Then, I fed that to al.exe with the target
set to an exe. I assumed that I had manually taken the same steps that csc
would do in one swoop to produce an exe. The newly gen'd exe would run
correctly, but it seems that it used the .netmodule as an external reference
(or dependence). When I removed the .netmodule file and tried to run the exe,
I got:

Unhandled Exception: System.IO.FileNotFoundException: File or assembly name
test.netmodule, or one of its dependencies, was not found.
File name: "test.netmodule"
at __EntryPoint()

I checked under ildasm comparing the two exes, and they were in fact
different. al.exe seemed to generate a new method called __EntryPoint() that
would call the external .netmodule. The one generated entirely with csc.exe
actually contained my main method within the exe. I wonder if there is
another way to use al.exe that does something more analogus to static linking
(if the analogy is apt at all). I'm guessing there is a way because csc does
result in a file that has no external depndencies. Everything's inside. This
further leads me to wonder if it's feasible to distribute .netmodule files if
they can be linked into and why that isn't a common practice.

Thanks...

-Ben

 

[Jon Skeet [C# MVP]]

Thanks for your answer. I could use a bit more clarification, though. From
what I can tell, there is reallyi no difference between a module and an
assembly except an assembly has a manifest as well. Is this correct?

Not quite - an assembly can contain more than one module.

If so, I
would assume that the assembly linker tool al.exe would simply add a manifest
to a module to produce an assembly. In my experimentation this was not the
case, though.

I first compiled a .cs file to a .exe with csc. Everything worked fine.

Next, for comparison, I compiled the .cs file with .csc but set the target
to module, and got test.netmodule. Then, I fed that to al.exe with the target
set to an exe. I assumed that I had manually taken the same steps that csc
would do in one swoop to produce an exe. The newly gen'd exe would run
correctly, but it seems that it used the .netmodule as an external reference
(or dependence). When I removed the .netmodule file and tried to run the exe,
I got:

Unhandled Exception: System.IO.FileNotFoundException: File or assembly name
test.netmodule, or one of its dependencies, was not found.
File name: "test.netmodule"
at __EntryPoint()

Indeed. That's created an assembly with a .exe containing just the
manifest, which tells it that it needs test.netmodule as part of the
assembly.

I checked under ildasm comparing the two exes, and they were in fact
different. al.exe seemed to generate a new method called __EntryPoint() that
would call the external .netmodule. The one generated entirely with csc.exe
actually contained my main method within the exe. I wonder if there is
another way to use al.exe that does something more analogus to static linking
(if the analogy is apt at all). I'm guessing there is a way because csc does
result in a file that has no external depndencies. Everything's inside. This
further leads me to wonder if it's feasible to distribute .netmodule files if
they can be linked into and why that isn't a common practice.

Multi-module assemblies are very rare, to be honest - there's rarely
any use for them, basically.