Understanding the .NET Framework - Assembly Manifest

(Page 6 of 8 )

The metadata in an assembly is called an assembly manifest, and it contains information about the types and resources that are externally visible outside the assembly. In addition, the metadata contains information about any dependencies that the assembly has. This includes information about dependent assembly names, their locations and their version number. Including the metadata information as a part of the assembly has a couple of important advantages. First, it finally eliminates the "DLL Hell" situation that continues to plague COM-based Windows applications; second, it frees the application from dependencies on the Windows Registry. "DLL Hell" describes an all-too-common error condition experienced by Windows applications where required new software installs inadvertently replace required application components such as DLLs with like-named components of a different version-which unfortunately are not completely compatible with the component they replace. When this happens, the new application typically works, but some existing application that depended on the old component broke. This was typically exacerbated by reinstalling the old software, which restored the original component and predictably broke the new application. Maintaining this versioning information in the metadata makes it possible to have side-by-side deployment where multiple versions of an assembly can be used simultaneously. Each assembly can load the dependent assemblies it needs without fear of using an incompatible component because the metadata specifies exactly which version of the component is required and where it is located. Because assemblies are self-describing, using the Registry isn't necessary to locate any of the dependent assemblies used in an application. Registering an assembly during installation is also unnecessary. This vastly simplifies the installation process and essentially enables xcopy style of deployment where assemblies can simply be copied to their destination system and executed. Table 2-8 presents the information that's contained in an assembly's manifest.

Item	Description
Assembly name	The assembly name.
Version number	The assembly's major and minor version number, and a revision and build number.
Culture	The region- and language-specific information about an assembly.
Strong name	The public key from the publisher for assemblies that use strong names. You can find more information about strong names in the "Assembly Security" section, later in this chapter.
List of all files	A list of all the files contained in the assembly and their filenames.
Type references	The information used by the CLR to map a type reference to the file that contains its declaration and implementation.
Referenced assemblies	List of assemblies that are statistically referenced by the current assembly. This list includes the assembly's name, metadata and public key, if the assembly is strong named.

Table 2-8. Assembly Manifest Information

Viewing Assembly Metadata

You can view the contents of an assembly by using the Ildasm.exe tool that is supplied with the .NET Framework SDK. The Ildasm.exe tool is essentially an assembly disassembler. You run the Ildasm.exe utility by selecting Start | Programs | Microsoft Visual Studio.NET | Visual Studio .NET Tools | Visual Studio Command Prompt. From there, you can enter ILDASM followed by the path and name of the .NET assembly that you want to inspect. Figure 2-5 illustrates viewing an assembly's metadata using the ILDASM utility.

In Figure 2-5, you can see the assembly information for the ADONetSample application that accompanies this book. In the metadata information shown in the figure, you can see that the manifest information is listed at the top of the assembly followed by the information about the MSIL executable code in the assembly. Double-clicking the Manifest line displays the following metadata information, which lists the contents of the assembly including its name, external dependencies, and resources.

Figure 2-5. Assembly metadata

.assembly extern mscorlib
{
     .publickeytoken = (B7 7A 5C 56 19 34 E0 89 ) //
.zV.4..
     .ver 1:0:3300:0
}
.assembly extern Microsoft.VisualBasic
{

     .publickeytoken = (B0 3F 5F 7F 11 D5 0A 3A ) //
.?_....:
     .ver 7:0:3300:0
}
.assembly extern System
{
     .publickeytoken = (B7 7A 5C 56 19 34 E0 89 ) //
.zV.4..
     .ver 1:0:3300:0
}
.assembly extern System.Data
{
     .publickeytoken = (B7 7A 5C 56 19 34 E0 89 ) //
.zV.4..
     .ver 1:0:3300:0
}
.assembly extern System.Drawing
{
     .publickeytoken = (B0 3F 5F 7F 11 D5 0A 3A ) //
.?_....:
     .ver 1:0:3300:0
}
.assembly extern System.Windows.Forms
{
     .publickeytoken = (B7 7A 5C 56 19 34 E0 89 ) //
.zV.4..
     .ver 1:0:3300:0
}
.assembly extern System.Xml
{
     .publickeytoken = (B7 7A 5C 56 19 34 E0 89 ) //
.zV.4..
     .ver 1:0:3300:0
}
.assembly extern Microsoft.Data.Odbc
{
     .publickeytoken = (B7 7A 5C 56 19 34 E0 89 ) //
.zV.4..
     .ver 1:0:3300:0
}
.assembly ADONETSample
{
     // --- The following custom attribute is added automatically, do not uncomment -------
     // NOTE: The following information has been truncated for presentation purposes
// .custom instance void [mscorlib]System.
                          Diagnostics.DebuggableAttribute::
     .custom instance void
[mscorlib]System.Runtime.InteropServices.GuidAttribute::
     .custom instance void [mscorlib]System.CLSCompliantAttribute::
     .custom instance void
[mscorlib]System.Reflection.AssemblyTrademarkAttribute::
     .custom instance void
[mscorlib]System.Reflection.AssemblyCopyrightAttribute::
     .custom instance void
[mscorlib]System.Reflection.AssemblyCompanyAttribute::
     .custom instance void
[mscorlib]System.Reflection.AssemblyDescriptionAttribute::
     .custom instance void
[mscorlib]System.Reflection.AssemblyTitleAttribute::
     .hash algorithm 0x00008004
     .ver 1:0:754:39738
}
.mresource public ADONETSample.Form1.resources
{
}
.module ADONETSample.exe
// MVID: {7ECCFC40-17DF-46D6-8E60-3188CD279A0A}
.imagebase 0x11000000
.subsystem 0x00000002
.file alignment 512
.corflags 0x00000001
// Image base: 0x02d90000

 

This is chapter two of ADO.NET: The Complete Reference, by Michael and Denielle Otey (McGraw-Hill/Osborne, ISBN 0-07-222898-9, 2003). Check it out at your favorite bookstore today. Buy this book now.

Next: Global Assembly Cache >>
 

More .NET Articles
More By McGraw-Hill/Osborne

Comments On: Understanding the .NET Framework

>>> Be the FIRST to comment on this article!