Metadata tables are collections of fixed-length records and columns. A metadata table contains a certain type of data, and each record is an instance of that type. Columns represent specific data on each instance, and each column contains either a constant or an index. An index in a metadata column references another table or heap and is also known as a metadata token. (Metadata heaps are explained in the next section.) Metadata tokens are used as metadata pointers, allowing tables to cross-reference each other. Metadata tables can be optimized (compressed) or not optimized. For the purpose of this book, it is assumed that metadata is optimized. Metadata that is not optimized requires intermediate tables for ordered access between tables.

Tokens are four-byte unsigned integers and a combination of the table identifier and RID. As shown in Figure 13-1, the first byte is the table identifier, and the last three bytes are the RID. A token referring to the Field table, for example, might be 0x04000002. This token refers to the second row of the Field table. RIDs start at one and are not zero-based. Because tokens are padded with zeros, the run time might optimize them. Metadata tokens are probably the most public manifestation of metadata. You will see metadata tokens often over the next few chapters of this book.

Figure 13-1. Layout of a metadata token

Metadata tables reference metadata heaps and other tables. Records of metadata tables hold fixed-length metadata information. Variable-length data is stored in one of the metadata heaps. Method signatures are an example of data placed on a metadata heap. They are variable-length and stored on the String heap.

The four metadata heaps are as follows: String, Userstring, Blob, and GUID.

Physically, metadata tables and heaps are persisted in streams. Six possible streams, including streams for each metadata heap, are available in .NET. There are also two mutually exclusive streams, optimized and nonoptimized, which are reserved for metadata tables. Metadata tables are either completely optimized or not optimized—there’s no such thing as partial optimization of metadata tables. If the metadata tables are optimized, the optimized stream is used. Otherwise, the nonoptimized stream is used. Therefore, any particular managed application has at most five streams. Table 13-2 provides a complete list of the metadata streams.

Successful execution of a managed application depends largely on metadata. Improperly formed metadata could cause a managed application to fail unceremoniously. An assembly with bad metadata is like a house built on quicksand. Loading a class, just-in-time compilation, code access security, and other run-time operations depend on robust metadata. Metadata validation tests the correctness of metadata and is performed preemptively, preventing applications with corrupt metadata from being executed. Preventing application crashes caused by improper metadata enforces code isolation.

Several tests are performed to validate metadata. Here is an abbreviated list of these tests:

You can use the PEVerify and Intermediate Language Disassembler (ILDASM) tools to validate metadata. Both tools are included in the .NET Framework software development kit (SDK).

PEVerify submits an assembly for metadata validation and Microsoft Intermediate Language (MSIL) verification and then reports the results. (MSIL verification is discussed in Chapter 14.) Run the PEVerify tool from a command prompt using the following basic syntax:

PEVerify assemblyname

PEVerify first validates the metadata of assemblyname. If metadata validation is successful, MSIL verification is conducted next. If metadata validation fails, the target assembly cannot be executed and MSIL verification is skipped. PEVerify offers a variety of optional arguments, including the option to perform MSIL verification even when the metadata validation fails.

Table 13-3 lists some of the PEVerify options.

The following is a simple "Hello World!" application, which is compiled to hello.exe. It is a minimal application, in which not much can go wrong. PEVerify will confirm this:

using System;

class Starter {
    static void Main() {
        Console.WriteLine("Hello, World!");
    }
}

The following output shows the result of running PEVerify on hello.exe with the /il and /clock options. Because the md command is omitted, metadata verification is skipped:

c:>peverify /il /clock hello.exe

All Classes and Methods in hello.exe Verified.
Timing: Total run     125 msec
        IL Ver.cycle  125 msec
        IL Ver.pure   93 msec

The elapsed cycle and pure verification times are listed. Pure verification time is the duration of the test, whereas cycle verification time also encompasses the startup and shutdown processes.

ILDASM is a .NET tool that also can perform various validations. In addition, you can use this tool to browse and display the metadata of an assembly—including the manifest. ILDASM inspects an assembly using reflection and can present the results in a window, console, or file.

ILDASM, which is a .NET disassembler and metadata browser, is a popular tool for developers. It proffers an internal representation of an assembly, which includes the metadata and MSIL code of an assembly in a variety of formats. ILDASM uses reflection to inspect an assembly. The basic command-line syntax of ILDASM requires only an assembly name, which opens ILDASM and displays the metadata of the assembly:

ildasm assemblyname

The following simple application is a basic .NET application that references a library. The application has a ZClass and a ZStruct type:

using System;

namespace Donis.CSharpBook {

    interface IA {
    }

    struct ZStruct {
    }

    class Starter {

        public static void Main() {
            ZClass obj1 = new ZClass();
            obj1.DisplayCreateTime();
            ZClass obj2 = new ZClass();
            obj2.DisplayCreateTime();
        }
    }

    class ZClass : IA {

    public enum Flag {
        aflag,
        bflag
    }

    public event EventHandler AEvent = null;

        public void DisplayCreateTime() {
            Console.WriteLine("ZClass created at " + m_Time);
        }

        private string m_Time = DateTime.Now.ToLongTimeString();
        public string Time {
            get {
                return m_Time;
            }
        }
    }
}

Figure 13-2 is a view of simple.exe from ILDASM. ILDASM displays a hierarchal object graph with an icon for each element of the application.

Figure 13-2. The simple.exe assembly displayed in ILDASM

Some icons are expandable or collapsible, as indicated by a + or – symbol, if you want to see more or less detail. The Assembly icon expands to show the details of the target assembly, the Namespace icon expands to show the members of the namespace, and so on. You can explore the object graph from the assembly down to the class members. Each icon depicts the category of item. Table 13-4 lists each icon and the action associated with double-clicking the icon.

Some elements are displayed twice. For example, a property is presented as itself and separately as accessor and mutator methods.

ILDASM has a variety of command-line options. Table 13-5 lists these parameters.

The user interface and command-line options for ILDASM are similar. The following command line is typical. It disassembles simple.exe and persists the resulting metadata, MSIL, metadata tokens, and source code to the simple.il file:

ildasm /out=simple.il /source /tokens simple.exe

The /source option of the preceding command interlaces MSIL code with source code. The source code is commented. Associating MSIL to source code relates each source statement to the resulting MSIL code, which is invaluable when debugging. The tokens shown per the /Tokens option are also commented.

The disassembly created by ILDASM is a valid MSIL program that can be recompiled For this reason the output text file should have an il extension, as in client.il. The assembly can be reassembled with the ILASM compiler, which compiles MSIL code. The newly assembled assembly is identical to the original assembly.

Some ILDASM options cause the assembly to be partially disassembled. When a partial disassembly occurs, you are presented with a warning. One limitation is that partial assemblies cannot be reassembled using ILASM. The following command creates a partial disassembly:

ildasm /out=simple.il /item=Donis.CSharpBook.ZClass simple.exe

The preceding command-line disassembles only the ZClass of the simple.exe assembly. Because other types are omitted from the disassembly, the result is a partial disassembly. For this reason, a warning is appended to the output. The following is a partial listing of the output file with the embedded warning:

//  Microsoft (R) .NET Framework IL Disassembler.  Version 3.5.21022.8
//  Copyright (c) Microsoft Corporation.  All rights reserved.

// warning : THIS IS A PARTIAL DISASSEMBLY, NOT SUITABLE FOR RE-ASSEMBLING

.class private auto ansi beforefieldinit Donis.CSharpBook.ZClass
       extends [mscorlib]System.Object
       implements Donis.CSharpBook.IA
{
  .class auto ansi sealed nested public Flag
         extends [mscorlib]System.Enum
  {
    .field public specialname rtspecialname int32 value__
    .field public static literal valuetype Donis.CSharpBook.ZClass/Flag
        aflag = int32(0x00000000)
    .field public static literal valuetype Donis.CSharpBook.ZClass/Flag
        bflag = int32(0x00000001)
  } // end of class Flag

  .field private class [mscorlib]System.EventHandler AEvent
  .field private string m_Time
  .method public hidebysig specialname instance void

Here is the final example of ILDASM and command-line options. The following command validates the metadata and persists the results to the simple.txt file:

ildasm /metadata=validate /out=simple.txt simple.exe