.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中,我们作了以下工作,来提高互操作的易用性。
网络广播:http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032417433&Culture=zh-CN
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的问题,给出了更好的解决方案。
自定义Stub来处理Interop中的Marshalling和目标函数调用;
5. 其他
Interop其他方面的改动,使用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,在保证了很高的兼容性的同时,做了大量的改进工作,在之后的一系列博客中,我们团队的成员会进一步作更为具体的介绍,敬请大家期待。