As part of its metadata, every assembly has a manifest. This describes what is in the assembly, including identification information (name, version, etc.), a list of the types and resources in the assembly, a map to connect public types with the implementing code, and a list of assemblies referenced by this assembly.
Even the simplest program has a manifest. You can examine that manifest using ILDasm, which is provided as part of your development environment. When you open it in ILDasm, the EXE program created by Example 12-3 looks like Figure 17-1.
Notice the manifest (second line from the top). Double-clicking the manifest opens a Manifest window, as shown in Figure 17-2.
This file serves as a map of the contents of the assembly. You can see in the first line the reference to the mscorlib assembly, which is referenced by this and every .NET application. The mscorlib assembly is the core library assembly for .NET and is available on every .NET platform.
The next assembly line is a reference to the assembly from Example 12-3. You can also see that this assembly consists of a single module. You can ignore the rest of the metadata for now.
Assemblies can consist of more than one module. In such a case, the manifest includes a hash code identifying each module to ensure that when the program executes, only the proper version of each module is loaded. If you have multiple versions of a given module on your machine, the hash code ensures that your program will load properly.
The hash is a numeric representation of the code for the module, and if the code is changed, the hash will not match.
Each module has a manifest of its own that is separate from the assembly manifest. The module manifest lists the assemblies referenced by that particular module. In addition, if the module declares any types, these are listed in the manifest along with the code to implement the module. A module can also contain resources, such as the images needed by that module.
The assembly manifest also contains references to other required assemblies. Each such reference includes the name of the other assembly, the version number and required culture, and optionally, the other assembly's originator. The originator is a digital signature for the developer or company that provided the other assembly.