CHAPTER 14 BUILDING AND CONFIGURING CLASS LIBRARIES
Exploring the Manifest
Before using CarLibrary.dll from a client application, let’s check out how the code library is composed
under the hood. Assuming you have compiled this project, load CarLibrary.dll into ildasm.exe via the
File Open menu, and navigate to the \bin\Debug subdirectory of your CarLibrary project. When you
are done, you should see your library displayed in the IL disassembler tool (see Figure 14-4).
Figure 14-4. CarLibrary.dll loaded into ildasm.exe
Now, open the manifest of CarLibrary.dll by double-clicking the MANIFEST icon. The first code
block in a manifest specifies all external assemblies required by the current assembly to function
correctly. As you recall, CarLibrary.dll made use of types within mscorlib.dll and
System.Windows.Forms.dll, both of which are listed in the manifest using the .assembly extern token, as
seen here:
.assembly extern mscorlib
{
.publickeytoken = (B7 7A 5C 56 19 34 E0 89 )
.ver 4:0:0:0
}
.assembly extern System.Windows.Forms
{
.publickeytoken = (B7 7A 5C 56 19 34 E0 89 )
.ver 4:0:0:0
}
Here, each .assembly extern block is qualified by the .publickeytoken and .ver directives. The
.publickeytoken instruction is present only if the assembly has been configured with a strong name
(more details on strong names in the section “Understanding Strong Names,” later in this chapter). The
.ver token defines (of course) the numerical version identifier of the referenced assembly.
After the external references, you will find a number of .custom tokens that identify assembly-level
attributes (copyright information, company name, assembly version, etc.). Here is a (very) partial listing
of this particular chunk of manifest data:
518