为了处理COM约定及其定义所引发的问题，Microsoft公司的COM与MTS小组计划开发一个新的组件平台，名为COM3。就在选定该名称不久，Microsoft的多个组织一致认为，在特定的Microsoft平台下，COM3这个名称并不合适。随即将其更名为公共对象运行库[Component Object Runtime(COR)]。在开发过程中，还采用过COM+在内的其他名称。很快地，又变为通用运行库[Universal Runtime(URT)]。在第一个beta版发布之前，最终将名称定为公共语言运行库[Common Language Runtime(CLR)]。

当我们论及CLR，就不得不比较规范（specification）与实现（implementation）的差别。作为.NET项目启动的一个环节，Microsoft曾向多个标准化组织提交过平台中的大部分。特别是，Microsoft向ECMA（http://www.ecma.org）提交了公共语言基础结构[Common Language Infrastructure(CLI)]。CLI包含了公共类型系统[Common Type System(CTS)]、公共中间语言[Common Intermediate Language(CIL)]、底层文件和元数据格式。不过，CLR本身没有成为向ECMA提交内容的一部分。准确地说，CLR是Microsoft所拥有并控制的CLI的一个实现。本书将不特意区分CLI规范与CLR之间的差别，因为截止到本书撰写时，还没有出现基于CLI的其他实现。

同COM平台一样，CLR也关注组件间的约定，并且，这些约定也都是基于类型的。不过，这也是两种约定的全部共同之处。

不同于COM，CLR自从问世以来，就有完全规范的格式描述组件之间的约定。这种格式一般称为元数据（metadata）。CLR元数据是机器可读的（machine-readable），其格式是完全规范的。此外，CLR提供了一些实用部件，使得程序员在不懂底层文件格式的情形下，就能够读写元数据。通过定制特性（Attribute；其本身就是强类型的），CLR元数据可以达到清晰容易的可扩展性。CLR元数据还包括组件的依赖关系和版本信息，这就允许使用一些新的技术来处理组件的版本控制问题。CLR元数据的存在是强制性的；你要部署或者加载组件，都必须访问元数据。同将元数据的存在作为可选项的环境（例如，COM）相比，构建基于CLR的基础架构和工具，显然要容易一些。
CLR约定与COM约定的第二个差别就是约定本身的特性。在COM中，组件约定暗示了堆栈约定、虚函数表，以及作为方法参数传递的数据结构在内存中的表示形式。在这方面，CLR和COM有着非常大的差异。

在CLR中，约定被描述为类型的逻辑结构。特别是，CLR约定不会描述任何数据的内存表示形式。CLR推迟确定有关内存的表示形式，直到在运行时类型被首次加载。约定的虚拟化（virtualization）很大程度上降低COM二进制约定所带来的不稳定性，这是因为组件间不存在任何内存表示形式的假设。
由于CLR类型定义是逻辑的，而不是物理的，因此，CLR的约定中并没有暗示访问字段或方法的精确的代码顺序。这样，在考虑虚方法布局、堆栈规则、对齐方式以及参数传递转换时，CLR具有极大的灵活性。并且，CLR的版本改变，不会带来组件的重新编译。因而，CLR通过名字与签名引用字段与方法，而不是偏移量。这样，CLR避免了困扰COM的声明顺序问题。成员的实际地址/偏移量需要等到在运行时类型被加载及初始化时才能够确定。

实现数据表示形式和方法地址的虚拟化有一个重要前提条件。由于约定的物理方面（例如，方法表/字段的位移量）在组件编译时都不知道，因此，就需要引进某种机制，延期这些位移量的解析，直到代码实际部署，以便在特定处理器构架中生成组件的最终版本。为了实现这个可能性，CLR的组件中几乎不包含机器代码，准确地说，基于CLR组件采用的公共中间语言[Common Intermediate Language(CIL)]用于他们的实现。

人们容易认为CIL只不过是个处理器无关（processor-neutral）的指令集，从而轻易地拒绝使用它。不过，即使只有一种处理器架构加入，CIL也是很重要的，这是因为CIL具有抽象能力，它将与机器代码密切关联的物理数据表示形式抽象出来。被CIL使用的操作码（opcode），在访问字段或调用方法时，不再使用绝对位移量或地址。准确地说，为了操作字段或方法，那些CIL会包含元数据的引用。这些引用只是基于字段或方法的名字与签名，而不是其位置或位移量。只要目标组件中存在与名字与签名匹配的字段或方法，CLR就没有必要选择物理位移量。

要注意，CLR不会直接执行CIL。准确地说，CIL在执行前总是被翻译为本机的机器语言。要么是在组件载入内存时，要么是组件被安装到部署机器上时，翻译就会被执行。无论哪种情况，当CIL到本机代码的翻译完成时，任何数据类型或方法的实际内存表示形式将被用于生成本机的机器代码，从而得到高效代码。

CIL生成的本机代码同样受益于高性能的物理耦合方式（physical coupling）,这也是C++和COM所采用的方式。然而，C++和COM在形式阶段就考虑这种物理耦合，而CLR在CIL到本机代码翻译发生之前，不会解析这种物理绑定的细节。由于翻译是在部署机器上翻译的，因此，部件以外所需的类型定义将与部署机器上的某个类型相匹配，而不是开发者的机器上。这极大的减少了跨组件约定的不可靠性，同时，又不降低性能。

最后，由于CIL到本机器代码的翻译发生在部署机器上，因此，任何用到的待定处理器布局或对齐规则（alignment rule）将与目标处理器架构（代码将在上面运行）匹配。软件也即将迎来另一个处理器迁移，即由现在的IA-32/Pentium架构向IA-64/Itanium架构发展。对于这次升级，CLR显得尤为重要。