基类库的变化与改进

自2005年以来，基类库就处于停滞之中。当其余的.NET框架基于CLR 2.0版本之上不断演进与构建时，基类库团队却在缓慢地构建他们的期望列表。跟随着.NET 4的脚步，CLR和BCL（基类库）的新版本也蓄势待发，一些改进也最终得到了实现。

新的类型

类似IronPython和F#的语言虽然简单，却与核心的.NET语言是完全背离的，它们具有真正的整数类型。VB和C#限制了整数必须符合给定的设置位，而这些语言实际上可以设置为任何值。但是，为了共享二者之间的价值，别说与其它语言，甚至是一个通用的实现都是需要的。基类库会添加一个类型BigInteger。这一高性能的实现是由BCL团队和Microsoft Solver Foundation一起联合开发的。

另一个主要为F#和IronPython添加的类型为Tuples。Tuples本身并无任何特别之处，本质上就是一个数据结构，能够存储一组固定长度的值。从某种程度上讲它就像是一个数组，但每个值都可以是不同的类型。与BigInteger相似，在基类库级引入它的主要原因是为了避免重复且不一致的实现。

在集合中新增的类为SortedSet。这是另外一个可以支持排序的对象集合的类，其中每个排序键必须是唯一的。目前仍然缺乏允许键重复的排序列表。

非托管的内存支持

在处理巨型文件时，真正的开发人员会转而使用一种技术，名为内存映射文件。顾名思义，一个内存映射文件将一个类似文件的结构映射到内存的地址中。除了实际的文件，设备与共享内存对象都能够被映射。使用内存映射文件的一种最常见的情形是内部进程通信。要做到这一点，每个应用程序都要打开相同的文件描述符。在BCL的下一个版本中，.NET开发人员将能够直接使用内存映射文件，而无需通过平台调用的方式。

国际化

.NET 4和Silverlight 2的资源管理器都将支持用户对UI语言的参数选择，而不是仅仅将其默认设置为CurrentUICulture链。当用户拥有多个首选语言时，这一功能就显得非常重要。

不一致的变化

在System.String中，好几个方法的默认比较逻辑都发生了变化。它不会影响到仅仅使用英语的应用程序，但可能会影响到国际化应用程序。

System.String（StartsWith，EndsWith，IndexOf和LastIndexOf）的默认部分的匹配重载被修改为默认与文化信息无关（顺序）。此外，System.String以及System.Char的ToUpper和ToLower则被修改为使用不可变的文化信息，而不是使用当前文化信息。虽然我们已经制定了编程指南以及FxCop规则，以建议开发者总是使用接受StringComparison参数的重载方法，但开发者总是不自觉地使用默认的重载方法。在.NET之前的版本中，默认的重载方法使用当前文化信息实现与文化信息相关的比较。当对此没有充分认识的开发人员，使用默认的重载方法执行安全敏感的字符串比较时，总会出现一些莫名其妙的错误，且具有明显的安全弱点，

性能改善

目前，Directory和DirectoryInfo的方法是返回数组。这就意味着在单个入口被访问之前，必须生成整个文件数组。随着IEnumerable对Directory和DirectoryInfo的额外支持，在目录的第一个文件被即刻访问时，列表的其余文件则可以延迟生成。

查看英文原文：Changes and Improvements to the Base Class Library