Metadata Validation

Metadata Validation

This “good hint,” however, is merely a hint. The definitions in the preceding section provide information about which tables we can reference from a column of a certain type. It does not mean that we should reference all the tables we can. Some of the groups of token types listed in Table 4-3 are wider than is actually acceptable in the first release of the common language runtime. For example, the MemberRefParent group, which describes the tables that can contain the parents of a MemberRef record, includes the TypeDef table. But the metadata emission APIs will not accept a TypeDef token as the parent token of a MemberRef; and even if such metadata was somehow emitted, the loader would reject it.

Even APIs provide very few safeguards (most of them fairly trivial) as far as metadata validity is concerned. Metadata is an extremely complex system, and literally hundreds of validity rules need to be enforced.

High-level language compilers, such as Microsoft Visual Basic .NET or Microsoft Visual C# .NET compilers, provide a significant level of protection against invalid metadata emission because they shield the actual metadata specification and emission from programmers. Because high-level languages are concept-driven and concept-based, and it is the compiler’s duty to relate the language concepts to the metadata structures and IL code constructs, a compiler can be built to emit valid structures and constructs. (Well, more or less.) On the other hand, ILAsm, like other assemblers, is a platform-oriented language and allows a programmer to generate an enormously wide range of metadata structures and IL constructs, only a fraction of which represent a valid subset.

In view of this bleak situation, we need to rely on external validation and verification tools. (Speaking of “validation and verification” is not an exercise in tautology—the term validation is usually applied to metadata, and verification to IL code.) One such tool is the common language runtime itself. The loader tests metadata against many of the validity rules, especially those whose violation could break the system. The runtime subsystem responsible for JIT compilation performs IL code verification. These processes are referred to as run-time validation and verification.

PEVerify, a stand-alone tool included in the .NET Framework SDK, offers more exhaustive validation and verification. PEVerify employs two independent subsystems, MDValidator and ILVerifier. MDValidator can also be invoked through the IL Disassembler.

You can find information about PEVerify and the IL Disassembler in the appendixes. Later chapters discuss various validity rules along with the related metadata structures and IL constructs.