.NET 自动垃圾管理（垃圾收集）、安全类型验证、丰富的调试支持、一致的方法出错行为、安全性、互操作性

 

自动垃圾管理：

CLR可以验证我们编写的所有代码都是类型安全的。类型安全性确保总是采取一直的方式来访问已分配的对象。假如一个方法的输入参数声明为接受一个4字节的值，那么CLR会检测并捕捉到该方法打算将参数作为一个8字节值来访问。类似的，假如一个对象在内存中占用了10个字节，应用程序就不能强迫对象转换成允许读取10个以上的字节的形式。类型安全性还意味着执行流程只能经过已知的位置（也就是方法的入口）。不能构造一个任意引用，让它随便指向一个内存位置，并造成那个位置的代码开始执行。所有这些措施确保了类型安全性，将许多常见的编程错误和典型的安全漏洞（比如缓冲区溢出）消除于无形。

 

丰富的调试支持：

由于CLR同时面向多种语言编程，所以现在可以根据一项特定的任务来挑选最合适的语言，从而使用不同的语言来实现应用程序的不同部分。对于这种跨越了语言边界的应用程序，CLR提供了完全的调试支持。

 

一致的方法出做行为：

以前进行Windows编程时，让开发人员特别苦恼的一个问题就是函数往往采取不一致的格式来报告错误。有的函数返回的是Win32状态码，有的函数返回的是Hresult，有的函数则抛出异常。在CLR中，所有错误都是通过异常来报告的。使用异常，开发人员可以将错误恢复代码与负责实际工作的代码隔离开。通过这种隔离，代码的编写、阅读、维护得到了显著的简化。除此之外，异常在工作时是跨越模块和语言边界的。另外，有别于状态码和Hresult，异常是无法忽略的。CLR还提供了内建的堆栈辗转开解机制，能够更容易地定位于任何bughe 错误。

 

安全性：

传统的操作系统安全性允许根据用户账号来提供隔离和访问控制。这个模型经过证明是行之有效的，但在其核心，已经假定所有代码都是得到了同等的信任。如果全部代码都是从物理媒体（比如：CD-ROM）或者可信的公司服务器上安装的，那么这个假定没有其他任何问题。但是，随着人么越来越多地依赖移动代码（比如web脚本、从Internet上下载的应用程序以及电子邮件附件等），我们需要采取一种进一步的以代码为中心的方式来控制应用程序的行为。代码访问安全性为此提供了一个解决方案。

 

互操作性：

Microsoft知道开发人员已经拥有数量相当大的现成代码和组件。要改写全部这些代码来充分利用.NET Framework平台，无疑是一项浩大的工程，而且可能妨碍人们快速采纳这一平台。所以，.NET Framework全面支持开发人员访问现有的COM组件，并调用现有的DLL中的Win32函数。