mscorlib.dll 和 System.dll答案

【问题标题】：mscorlib.dll & System.dllmscorlib.dll 和 System.dll
【发布时间】：2010-09-28 23:46:16
【问题描述】：

为什么 MS 最初决定维护这两个独立的核心库？也许他们考虑到了一些可扩展性问题，但现在我从未见过任何类型的应用程序不需要两者。有人有这方面的内幕消息吗？这不是很重要，但多年来一直在我的脑海中。

PS。我知道这两个库中有什么，我知道区别 - 我是 Reflector 的忠实粉丝 :) 只是想知道将两者分开有什么实际用途。

【问题讨论】：

标签： .net assemblies

【解决方案1】：

这只是一个猜测，但 mscorlib.dll 可能还有一些对 CLR 运行时很重要的 C 代码以及 .NET 程序集或一些混合模式代码。 System.dll 可能都是托管的。

【讨论】：

【解决方案2】：

仔细查看任何项目的引用节点。您永远不会找到那里列出的 mscorlib.dll。它很特别，任何编译器都需要它，因为它包含使语言语法工作所需的类型。 System.Array、System.Int32、System.String、System.Exception等

您可以编写一个不依赖于 System.dll 的程序（尽管这会很困难），但您不能编写一个不依赖于 mscorlib.dll 的程序

【讨论】：

是的，您可以 - 只需使用 csc 和 /nostdlib[+|-] 开关
我的理解是 /nostdlib 只影响编译器导入的符号。我相信无论您做什么，您的进程在运行时都会加载 mscorlib。
好吧，假设您将其加载到 MS 的 .NET 实现中...将其加载到单声道中，它可能不会。
我认为 mono 在运行时仍然需要 mscorlib（我可能错了）。程序集名称是 clr 类型标识的一部分。 mscorlib.dll 中的 System.Object 与 foo.dll 中的 System.Obect 类型不同。没有对象，程序就无法运行。您可以替换/构建自定义 mscorlib，但它仍然是必需的。
/nostdlib 旨在让编译器使用 another 版本的 mscorlib 参考程序集。例如，在 Silverlight 项目中需要。

【解决方案3】：

~~Mscorlib 确实包含本机代码和托管代码。~~

除其他外，它还包含 System.Object 实现，它必须始终存在才能使一切正常工作。

它的区别在于它是 CLR 需要在每个托管进程中加载的唯一程序集。

最初，很多“可选”的东西（技术上不需要运行应用程序的东西）被放入 mscorlib，因为它们很可能被每个人使用。这包括像 HashTable 和 List 这样的东西。

这提高了性能。如果每个人都想使用某些东西，那么将它放在每个人都必须加载的程序集中是有意义的。这样您就不必浪费时间去绑定一大堆不同的程序集了。

system.dll 中的内容基本上是所有不“值得”包含在 mscorlib 中的东西。

然而，这种趋势开始逆转。 CLR 正在努力减小 mscorlib 的大小。例如，为 Silverlight 删除了很多内容（以减少下载大小）。

我认为他们可能会为 V4（及更高版本）做更多此类事情，但我不确定细节。

【讨论】：

这有点挑剔，但正如@Justin Van Patten 提到的，mscorlib.dll 不包含任何本机代码。相反，它具有用[MethodImpl(MethodImplOptions.InternalCall)] 注释的外部方法，这些方法调用CLR。如果浏览 SSCLI 源，您可以看到这些 CLR 方法导出以供 mscorlib 使用。
从技术上讲，它确实包含一些本机节点（PE 标头中的 msdos 存根），但通常您是对的。我编辑了帖子以反映这一点。

【解决方案4】：

提到的本机/托管的东西听起来很合理，但我仍然不完全相信。无论如何，MS 似乎将 mscorlib.dll 视为 system 所需的核心库，而 System.dll 包含 programmers 的核心功能 - 这听起来也不错。

我刚刚将同样的问题通过电子邮件发送给 BCL 团队。如果任何人可以回答...当（如果？）我收到答案时，我会在此处发布。感谢您到目前为止的回答！

【讨论】：

【解决方案5】：

扩展 Scott 的答案。

任何给定版本的 CLR 都与特定版本的 mscorlib.dll 高度相关。它在很多方面都是一个特殊 DLL。 CLR 运行时要求某些类型/方法可用，并实现实际代码库中定义的许多方法。通过在 CLR 版本和 mscorlib 版本之间建立牢不可破的链接，可以降低管理这种关系的复杂性。

【讨论】：

不知道我是否应该将 Scott 的或你的设置为接受的答案，抱歉。最后，我决定选择斯科特的，但你的也一样好。
Scott's 更完整。我刚刚击中了他错过的一点。我投票给他。

【解决方案6】：

我在 CLR/BCL 团队工作，刚刚回复了您的电子邮件。这里贴在下面：

Jared 对 Stack Overflow 的回答是对了。 mscorlib.dll 紧绑定到 CLR 的原因是他提到。请注意，mscorlib.dll 本身不包含任何本机代码（正如斯科特建议的那样），但是有许多地方需要打电话直接进入CLR。因此， CLR 和 mscorlib 必须进行版本控制在一起。

另一方面，System.dll 不是紧密绑定到 CLR（它不需要对运行时的任何调用）。我们认为 System.dll 位于比 mscorlib.dll 更高的层。将这些程序集分为两个单独的层允许更多灵活性，使其更容易版本 System.dll 与 CLR/mscorlib.dll 版本（如果我们想要这样做）。理论上，我们可以使更改并添加功能 System.dll 无需加速 CLR/mscorlib 版本。分离也更容易管理组件之间的依赖规则这些不同的层。

正如斯科特提到的，它看起来确实像里面有很多“可选”的东西 mscorlib。这主要是为了历史原因和一些东西只是别人需要的事物。例如，没有技术原因 System.IO.IsolatedStorage 需要在 mscorlib 中，但这就是它的位置碰巧在 1.0 中添加，在我们之前真的想过这样版本控制/分层问题。还，列表在 mscorlib 中，因为其他 mscorlib 中的代码需要一个基本列表集合。

从长远来看，我们希望减少 mscorlib 中“可选”内容的数量越多越好。或者通过将东西推出 mscorlib 或创建一个新的、更核心的组件只包含最低限度必要的类型（例如 System.Object， System.Int32 等）进行托管代码工作。这将给我们灵活地添加新的创新 “可选”的东西，并做出来更容易创建不同的 .NET 框架 SKU（例如 .NET 客户端 Profile、Silverlight 等），无必须修改运行时。

我希望这会有所帮助！

谢谢，贾斯汀

【讨论】：

团队如何决定将程序集命名为 mscorlib？我经常想知道 ms 前缀和 8.3 文件名。
检查版本信息它被称为：“微软公共语言运行时类库”。但据我所知，它也是“Multilanguage Standard Common Object Runtime Library”的首字母缩写，它是在 CLI 的 EMCA 标准化期间创建的。