CLR 4 新特性 ------ 概览

.NET 4中发布了最新版本的公共语言运行时，简称CLR (Common Language Runtime) 。这个版本是CLR 2.0之后又一个新的版本，包含着CLR小组几年以来的辛勤工作。

CLR上海团队计划在未来的几个月内陆续介绍其中的一些特性，本文作为一个概览，先作蜻蜓点水，抛砖引玉。也欢迎大家回复本文，告诉我们你所感兴趣的话题，我们会进一步作深入的介绍。

CLR 简介

CLR作为.NET框架中最为底层的部件，扮演着运行托管代码虚拟机的角色，承担着诸如即时编译(Just In Time Compile)，垃圾回收(Garbage Collect)等任务。打一个比方，如果把操作系统看做是运行二进制程序的宿主，那么CLR就是托管世界的操作系统。

图一 CLR 在.NET框架中所处的位置

CLR作为.NET框架中的一部分，总是跟着.NET发行，但是近年来.NET的发行版本从2.0一直到3.5, 但是CLR却还一直保留在2.0，如下表所示：

.NET框架版本	时间	CLR
1.0	2002.2	1.0
1.1	2003.4	1.1
2.0 (Generics)	2006.1	2.0
3.0 (WPF/WCF/WF)	2006.11	2.0
3.5 (LINQ)	2007.11	2.0
4.0 Beta	2009.5	4.0

图二 CLR 版本

大家可以看到，2.0的发行已经是三年之前的事情了，在这几年中，CLR小组的工作最后都汇集在了这次发行之中，可谓是众星云集，下面我们一一叙来。

托管与本地代码的互操作

托管代码与本地代码之间的互操作(interop)担负着.NET世界对外联系的责任。比如调用一个本地dll或者COM组件。在CLR 4中，我们作了以下工作，来提高互操作的易用性。

1. 自定义QI(Custom QI)

当托管代码被COM调用的时候，它扮演着COM组件的角色。对于COM组件来说，IUnknown::QueryInerface(QI)是类型转化的关键。CLR4之前，为每个托管COM组件提供了一个QI实现; CLR4 允许用户自定义QI，大家可以从mscorlib中新增的interface，System.Runtime.InteropServices.ICustomQueryInterface着手了解这一新功能。

2. TlbImp源代码以及自定义工具

在托管代码中调用COM组件，需要这个COM组件用托管语言申明自己的接口，也就是Interop Assembly(IA)。在一般情况下，用户不需要自己动手撰写这些assembly，而可以使用TlbImp这个工具，根据TLB生成IA。在CLR 4的开发中，我们用托管代码把TlbImp重写了，并且把源代码公布在了codeplex上面。

发布TlbImp的源代码的好处之一，是方便使用者根据自己的需求，通过修改源代码来自拓展TlbImp的功能。我们也收集了很多客户需要自定义TlbImp的要求，并且提取了一些呼声最高的自定义请求，制作了TlbImp自定义工具，也在codeplex发行。详见http://blogs.msdn.com/silverlightshanghai/archive/2009/03/13/codeplex-tlbimp.aspx

3. 等价类型

前面提到，COM组件要为.NET所用，需要Interop Assembly。不同版本的COM组件，带来了部署上的问题。在CLR 4.0之中，我们通过等价类型的引入，就部署IA的问题，给出了更好的解决方案。

4. 其他

Interop其他方面的改动，包括自定义Stub来处理Interop中的Marshalling和目标函数调用；使用COM取代了原先的远程对象访问；让用户自己决定清理RCW的时机等等，会有更为详细的博文作具体介绍。

垃圾回收

垃圾回收一直是CLR中的核心模块，对托管程序运行的性能至关重要。在这个版本中，CLR引入了background GC，和原来的Concurrent GC相比，在GC进行的过程中，会更少的阻断其他进程，从而提高整个CLR的运行效率。同时，此前在sp2中引入的GC::RegisterForFullGCNotification可以让 CLR4.0可以通知用户第二代GC发生，从而使服务器有机会处理负载平衡，使得整个服务器端的处理能力不至于因为GC的发生受到太大的影响。

代码约定

在CLR4.0中，引入了代码约定，更方便用户规范代码的行为，大家可以从System.Diagnostics.Contracts这一命名空间着手，进一步了解其内容。

Corrupted state exception

CLR 4.0中，对异常处理的哲学有了一个改进：在默认情况下，try/catch语句将不能捕获诸如AccessViolationException等异常。因为这些异常的损毁(Corrupt)了机器的状态(state)，即使用户捕获了它们，也无法继续执行代码，或者说，继续执行代码也会变得非常危险。

新的安全模型

用过CLR v2的安全模型的朋友们可能还会记得诸如Evidence，Policy以及Permission等概念，这些复杂的对象一起构筑了v2的安全模型的框架，CLR4.0中，安全模型被大大简化，SecurityCritical，SecurSafeCritical等一些安全级别构筑了新的安全模型的基础。

同一个进程，多个CLR

CLR4.0的出现，又添加了一个CLR的版本，尽管我们尽量保证各个不同版本之间的兼容性，但是还是可能出现一些已经开发的组件，需要特定的版本才能运行。为了确保用户过去编写的组件不会因为新的CLR版本而不能运行，CLR4.0中允许用户在一个进程中，运行不同的CLR版本，这样不同的组建就可以各取所需，运行在适合他们的CLR中了。

基本类库

基本类库，也就是mscorlib.dll，包括了诸如System.Object这样在整个类型系统中最为核心的类库。CLR4.0也包含了很多新功能：比如用于支持动态语言的System.Tuple,新的集合类型System.Collections.Generic.SortedSet，用于提高文件系统浏览性能的API，操作注册表的API，以及对内存映射文件的支持等等。

 

总的来说，CLR4.0相较于CLR2.0，在保证了很高的兼容性的同时，做了大量的改进工作，在之后的一系列博客中，我们团队的成员会进一步作更为具体的介绍，敬请大家期待。