为什么MS最初决定维护这两个独立的核心库？也许他们考虑到了一些可伸缩性问题,但是现在我从来没有看到任何类型的应用程序都不需要这两者.有没有人有这方面的内幕消息？这不是很重要,但多年来一直在我的脑海里.
PS.我知道两个库中有什么,我知道不同之处 - 我是Reflector的忠实粉丝:)只是想知道两者的分离有什么实际用途.
我在CLR/BCL团队工作,刚回答了你的电子邮件.它粘贴在下面:
Jared对Stack Overflow的回答是正确的.由于他提到的原因,mscorlib.dll与CLR紧密绑定.请注意,mscorlib.dll本身不包含任何本机代码(如Scott建议的那样),但是有很多地方需要直接调用CLR.因此,CLR和mscorlib必须一起版本化.
另一方面,System.dll没有与CLR紧密绑定(它不需要对运行时进行任何调用).我们认为System.dll位于比mscorlib.dll更高的层.将这些程序集放在两个单独的层中可以提供更大的灵活性,从而可以更轻松地将System.dll与CLR/mscorlib.dll版本分开编辑(如果我们想这样做).理论上,我们可以在不加速CLR/mscorlib版本的情况下对System.dll进行更改和添加功能.分离还使得更容易管理这些不同层中的组件之间的依赖性规则.
正如斯科特提到的那样,mscorlib似乎有很多"可选"的东西.这主要是出于历史原因,并且因为其他事情只需要一些东西.例如,System.IO.IsolatedStorage需要在mscorlib中没有技术上的原因,但在我们真正考虑这种版本控制/分层问题之前,这就是它恰好在1.0中添加的地方.此外,List位于mscorlib中,因为mscorlib中的其他代码需要基本列表集合.
从长远来看,我们希望尽可能减少mscorlib中"可选"的数量.通过从mscorlib中推出东西或创建一个新的,更核心的程序集,它只包含最小的必要类型(例如System.Object,System.Int32等),以使托管代码工作.这将使我们能够灵活地为"可选"内容添加新的创新,并且可以更轻松地创建不同的.NET Framework SKU(例如.NET客户端配置文件,Silverlight等),而无需修改运行时.
我希望这有帮助!
谢谢,贾斯汀
Mscorlib包含本机代码和托管代码.
除此之外,它还包含System.Object实现,它必须始终存在才能使一切工作.
它的区别在于CLR需要在每个托管进程中加载的唯一程序集.
最初,许多"可选"的东西(技术上不需要运行应用程序的东西)被放入mscorlib,因为它们很可能被所有人使用.这包括HashTable和List之类的东西.
这给了性能提升.如果每个人都想要使用某些东西,那么将它放入每个人都必须加载的程序集中是有意义的.然后你不必浪费时间去绑定一大堆不同的组件.
system.dll中的东西基本上都是没有"值得"包含在mscorlib中的东西.
然而,这种趋势开始逆转.CLR正在努力减小mscorlib的大小.例如,为Silverlight删除了很多东西(减少下载大小).
我认为他们可能会为V4(以及更高版本)做更多这类东西,但我不确定细节.
扩展斯科特的答案.
任何给定版本的CLR都与特定版本的mscorlib.dll高度相关.它在很多方面都是一个特殊的 DLL.CLR运行时需要某些类型/方法可用,并实现在实际代码库中定义的许多方法.通过在CLR版本和mscorlib版本之间建立牢不可破的链接,可以降低管理此关系的复杂性.
仔细查看任何项目的References节点.你永远不会在那里找到mscorlib.dll.它很特殊,任何编译器都需要它,因为它包含使语言语法工作所需的类型.System.Array,System.Int32,System.String,System.Exception等.
你可以编写一个不依赖于System.dll的程序(虽然它很难),但你不能编写一个不依赖于mscorlib.dll的程序
京公网安备 11010802040832号 | 京ICP备19059560号-6 