Assembly
Structure:
An
assembly consists of assembly metadata describing the complete assembly, type
metadata describing the exported types and methods, MSIL code, and resources.
All these parts can be inside one file or spread across several files.
In the
following eg, the assembly metadata, type metadata, MSIL code, and resources
are all in one file – component.dll, the assembly consists of a single file.
Component.dll
Assembly Metadata
Type Metadata
IL Code
Resources
|
|
Assembly
meta data also references a module call util.netmodule, which itself includes
only type meta data and MSIL code for a class. A module has no assembly
metadata. Thus the module itself has no version information; it also cannot be
installed separately. All the three files in this ex make up a single assembly.
The assembly is the installation Unit.
NAMESPACES, ASSEMBLIES, AND
COMPONENTS
How
does a namespace fit into the assembly concept? The namespace is completely
independent of an assembly. You can have different namespaces in a single
assembly, but the same namespace can spread across assemblies. The namespace is
just an extension of the type name
Assemblies
can be viewed using the command line utility ildasm, the MSIL disassembler. An
assemply can be opened by starting ildasm from the command line, with the
assembly as argument or by selectin ghte menu File-open.
Understanding
Strong assembly names
All
assemblies contain a name, version, and a culture. However assemblies can
contain a public key. An assembly containing all four pieces of information is
said to be strongly named. Only
assemblies that contain strong names can be stored in the global assembly.GAC is a disk based collection of .NET assemblies
that can be accessed by any piece of .NET code on the machine containing the
GAC. You can place assemblies with different strong names side by side in the
global assembly cache, even if the segment names match. For example version
1.0.0.0 of an assembly named assembly.dll can be installed in GAC along with
version 2.0.0.0