元数据和验证
然而，这个“好的暗示”，仅仅是一个暗示。在前述的部分提供了关于你可以从一个列的确定的类型引用哪些表的信息。这并不意味着你应该引用所有你能够引用的表。在表5-10中列出的一些群组的符号类型比在CLR现有的发布版本中实际上可接受的要更加广阔。例如，MemberRefParent群组，描述了能够包含MemberRef记录的父级别的表，包括TypeDef表。但是这个元数据发布API不会接受TypeDef符号作为MemberRef的父级别符号；并且即使这样的元数据不知何故还是发布出来了，加载器将会忽略它。
元数据发布API提供了非常少的安全保证（它们中的大多数是相当琐碎的）直到元数据有效性被涉及。元数据是一个极其复杂的系统，并且是文字上的数以百计的需要被强制执行的有效性规则。
高级别的语言编译器，如VB.NET或C#，对元数据发布提供了一个重要级别的保护，因为它们防止了来自程序员的确切的元数据规格说明和发布。这种高级别语言是概念取代的和基于概念的，并且这是编译器的职责来把语言概念转换为元数据结构和IL代码构造，因此一个编译器可以被建造用来发布有效的结构和构造（好吧，或多或少。）另一方面，ILAsm，就像其它的编译器，是一个面向平台的语言并允许程序员生成巨大的范围的元数据结构和IL构造，其中只有小部分代表着一个有效的子集。
考虑到这种的艰难的情形，我们需要依赖于外部的有效性和验证性工具（说到有效性和验证不是在同义反复的练习——在CLR术语中，有效性经常应用于元数据，验证性择应用于IL代码。）一个这样的工具就是CLR本身。加载器依靠很多有效性工具来测试元数据，尤其是那些可以破坏系统的侵害。负责JIT编译器的运行时子系统执行IL代码的验证。这些工程被称为“运行时有效性和验证”。
PEVerify，一个独立的包括在.NET Framework SDK中的工具，提供了更彻底的有效性和验证。PEVerify使用了两种独立的子系统，MDValidator和ILVerifier。MDValidator也可以在IL反编译器中被调用。
你可以发现在附录中发现PEVerify 和IL反编译器的信息。后面的章节讨论了各种各样的有效性规则并伴随着相关的元数据结构和IL构造。