The Role of Assemblies, Manifests and ILDasm
.NET introduces the concept of an assembly. A single file assembly is a collection of types compiled into a
single DLL or EXE file. Most .NET assemblies are of the single file variety. A multifile assembly is composed
of any number of files such as DLLs or EXEs, resource files, HTML files, images, XML files, etc.
Assemblies are reusable, versionable, and self-describing.
From a physical level, most assemblies are a single DLL or EXE file. This is a single file assembly. This binary
file (the assembly) is a collection of types (classes, interfaces, structures, enumerations, delegates) within some
number of namespaces. Be aware that the name of the assembly does not need to match the name of the
contained namespace(s).
Consider, for example, the core .NET assembly, mscorlib.dll. This single *.dll assembly has been organized into
numerous namespaces. Each namespace has some number of types. Each type as some number of members
(constructors, functions, properties, events, etc).
Be aware that .NET does support the construction of multifile assemblies, where a set of .NET assemblies are
versioned and deployed as a single logical unit. This flavor of assemblies can be helpful for remote distributions
as the client machine is able to download discrete binaries on demand rather than downloading a large single file
assembly. A multifile assembly has a primary module that takes a *.dll file extension. This is the file that
external applications directly reference. The additional modules of a multifile assembly take a *.netmodule file
extension as a naming convention. These are loaded on demand as needed by the client software. Thus, although
a multifile assembly is physically composed of multiple units, it is logically seen as a collection of types.
Every assembly contains a manifest that documents key pieces of assembly information, including the
following. The assembly version, culture, optional security settings, optional resources, and optional ‘strong
name’ information (more details later). The collection of files that compose the assembly (if it is a multifile
assembly). Any assembly level attributes.
You can investigate the contents of an assembly using tools such as ILDasm.exe. This tool displays the manifest
of an assembly and the internal CIL code instructions. This tool ships with the .NET SDK and is also part of a
Visual Studio installation.
And here is the manifest:
Assemblies contain type metadata that describe each type in the assembly. You can view this metadata by
typing “ctrl+m” in ILDasm.exe:
Use the System.Reflection namespace to discover this same information at runtime. Reflection is the .NET
service that provides information about the types within an assembly. The System.Type class is used to hold
metadata information for a given type in an assembly. System.Reflection.Assembly is used to find and load a
given assembly (more details later).
.NET introduces the concept of an assembly. A single file assembly is a collection of types compiled into a
single DLL or EXE file. Most .NET assemblies are of the single file variety. A multifile assembly is composed
of any number of files such as DLLs or EXEs, resource files, HTML files, images, XML files, etc.
Assemblies are reusable, versionable, and self-describing.
From a physical level, most assemblies are a single DLL or EXE file. This is a single file assembly. This binary
file (the assembly) is a collection of types (classes, interfaces, structures, enumerations, delegates) within some
number of namespaces. Be aware that the name of the assembly does not need to match the name of the
contained namespace(s).
Consider, for example, the core .NET assembly, mscorlib.dll. This single *.dll assembly has been organized into
numerous namespaces. Each namespace has some number of types. Each type as some number of members
(constructors, functions, properties, events, etc).
Be aware that .NET does support the construction of multifile assemblies, where a set of .NET assemblies are
versioned and deployed as a single logical unit. This flavor of assemblies can be helpful for remote distributions
as the client machine is able to download discrete binaries on demand rather than downloading a large single file
assembly. A multifile assembly has a primary module that takes a *.dll file extension. This is the file that
external applications directly reference. The additional modules of a multifile assembly take a *.netmodule file
extension as a naming convention. These are loaded on demand as needed by the client software. Thus, although
a multifile assembly is physically composed of multiple units, it is logically seen as a collection of types.
Every assembly contains a manifest that documents key pieces of assembly information, including the
following. The assembly version, culture, optional security settings, optional resources, and optional ‘strong
name’ information (more details later). The collection of files that compose the assembly (if it is a multifile
assembly). Any assembly level attributes.
You can investigate the contents of an assembly using tools such as ILDasm.exe. This tool displays the manifest
of an assembly and the internal CIL code instructions. This tool ships with the .NET SDK and is also part of a
Visual Studio installation.
And here is the manifest:
Assemblies contain type metadata that describe each type in the assembly. You can view this metadata by
typing “ctrl+m” in ILDasm.exe:
Use the System.Reflection namespace to discover this same information at runtime. Reflection is the .NET
service that provides information about the types within an assembly. The System.Type class is used to hold
metadata information for a given type in an assembly. System.Reflection.Assembly is used to find and load a
given assembly (more details later).
Assemblies, Manifests, ILDasm
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
Table of Contents
| C# Tutorial | C#.NET Tutorial | Manifests Tutorial Copyright (c) 2008. Intertech, Inc. All Rights Reserved. This information is to be used exclusively as an online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited. |
Courseware
Training Resources
Tutorials
Services