【IT168 技术文档】.NET结合了Java和COM两者优点来解决互操作性问题。类似于COM定义的标准二进制格式，.NET定义了一个称为通用类型系统（Common Type System）的类型标准。这个类型系统不但实现了COM的变量兼容类型，而且还定义了通过用户自定义类型的方式来进行类型扩展。任何以.NET平台作为目标的语言必须建立它的数据类型与CTS的类型间的映射。
所有.NET语言共享这一类型系统，实现他们之间无缝的互操作。该方案提供了语言之间的继承性。eg：用户能够在vb.net中派生一个由c#编写的类。
很显然，编程语言的区别不仅仅是类型。eg：一些语言支持多继承，一些语言支持无符号数据类型，一些语言支持运算符重载。因此，.NET通过定义公共语言规范（Common Language Specification）来限制了由这些不同引发的互操作性问题。
CLS制定了一种以.NET平台为目标的语言所必须支持的最小特征，以及该语言与其他.NET语言之间实现互操作性所需要的完备特征。这里的特征已经不是语言间的简单语法区别。eg：CLS并不关心一种语言用什么关键字实现继承，只关心该语言如何支持继承。
CLS是CTS的子集。这就意味着一种语言特征可能符合CTS标准，但有超过了CLS的规范。eg：C#支持无符号数字类型，该特征能通过CTS测试，但CLS却仅仅识别符号数字类型。因此，如果用户在一个组件类使用C#的无符号类型，就可能不能与不使用无符号类型的语言（eg： VB.NET）设计的组件实现互操作。这里说的是“可能不”，而不是“不可能”，因为这一问题事件依赖于对non-CLS-compliant项的可见性。事实上，CLS规范只适用于或部分适用于那些与其他组件存在联系的组建中的类型。
实际上，用户能够安全事项含有私有组件的项目，而该组件使用了用户所选择使用的.NET语言的全部功能，且无需遵守CLS规范。另一方面，如果用户需要.NET语言的互操作性，那么用户的组件中的公共项必须完全符合CLS规范。让我们来看下面的C#代码：
{
// The uint(unsigned integer)type is non-CLS compliant.
//But since this item is private,the CLS rules do not apply.
private uint A = 4;
// Since shis uint member is public,we have a CLS
// compliance issue.
public uint B = 5;
// The long type is CLS compliant.
public long GetA()
{
return A;
}
}
最后一个C是公共语言运行库Common Language Runtime(CLR)。简单地说，CLR是CTS的实现，也就是说，CLR是应用程序的执行引擎和功能齐全的类库，该类库严格按照CTS规范实现。作为程序执行引擎，CLR负责安全地载入和运行用户程序代码，包括对不用对象的垃圾回收和安全检查。在CLR监控之下运行的代码，称为托管代码(managed code)。
作为类库，CLR提供上百个可用的有用类型，而这些类型可通过继承进行扩展。对于文件I/O、创建对话框、启动线程等类型—— 基本上能使用Windows API来完成的操作，都可由其完成。
让我们正确看待“3C”。开发人员在构建自己的分布式应用程序时，因为用户在编程时将直接面对CLR，应将主要精力放在学习了解CLR上，而不是CTS和CLS。而对于希望以.NET平台为目标的语言和工具开发商来说，就需要深入理解CTS和CLS。互操作性组件是分布式应用的关键，因此理解.NET如何通过定义公共类型实现这一目标，也就显得十分重要。
