.net mscorlib.dll & System.dll

mscorlib.dll & System.dll

提问by user39603

Why did MS originally make the decision to maintain these two separate core libs? Maybe they had some scalability issue in mind, but nowadays I never see an application, of any type, that doesn't need both. Does anyone have any inside information on this? It's not really important, but been on my mind for years.

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

PS. I know what's in the two libs, I know the difference - I'm a big fan of Reflector:) Just wondering what practical use the separation of the two has.

附注。我知道这两个库中有什么，我知道它们之间的区别——我是Reflector 的忠实粉丝:) 只是想知道将两者分开有什么实际用途。

采纳答案by Scott Wisniewski

Mscorlib does contains both native and managed code.

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

Amongst other things it contains the System.Object implementation, which must always be present in order for everything to work.

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

It has the distinction of being the only assembly that the CLR requires to be loaded inside every managed process.

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

Originally, a lot of "optional" stuff (things that technically aren't required to run an app) was put into mscorlib because they were things that were highly likely to be used by everybody. This includes things like HashTable and List.

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

This gave a perf boost. If everybody is going to want to use something, then it makes sense to put it inside the assembly that everybody has to load. Then you don't have to waste time going and binding a whole bunch of different assemblies.

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

The stuff in system.dll was basically everything that wasn't "worthy" of being included in mscorlib.

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

This trend, however, is starting to be reversed. The CLR is making efforts to reduce the size of mscorlib. A lot of stuff was removed for Silverlight for example (to reduce download size).

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

I think they might be doing more of this kind of stuff for V4 (and later versions) but I'm not sure about the details.

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

回答by Justin Van Patten

I work on the CLR/BCL team and just answered your email. Here it is pasted below:

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

Jared's answer on Stack Overflow is right on. mscorlib.dll is tightly bound to the CLR for the reasons he mentions. Note that mscorlib.dll itself doesn't contain any native code (as Scott suggests), but there are many places where it needs to call directly into the CLR. As such, the CLR and mscorlib must be versioned together.

System.dll on the other hand is not tightly bound to the CLR (it doesn't require any calls into the runtime). We consider System.dll to be at a higher layer than mscorlib.dll. Having these assemblies in two separate layers allows for more flexibility, making it easier to version System.dll separately from the CLR/mscorlib.dll version (if we wanted to do so). We could, in theory, make changes and add functionality to System.dll without revving the CLR/mscorlib version. The separation also makes it easier to manage dependency rules between components in these different layers.

As Scott mentions, it does seem like there's a lot of "optional" stuff in mscorlib. This is mainly for historical reasons and because some things are just needed by other things. For example, there's no technical reason why System.IO.IsolatedStorage needs to be in mscorlib, but that's just where it happened to be added in 1.0, before we really thought about such versioning/layering concerns. Also, List is in mscorlib because other code in mscorlib has a need for a basic list collection.

Long term we'd like to reduce the amount of "optional" stuff in mscorlib as much as possible. Either by pushing stuff out of mscorlib or creating a new, more core, assembly that just contains the bare minimum necessary types (e.g. System.Object, System.Int32, etc.) to make managed code work. This will give us the flexibility to add new innovations to the "optional" stuff, and make it easier to create different .NET Framework SKUs (e.g. the .NET Client Profile, Silverlight, etc.), without having to rev the runtime.

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 进行更改和添加功能。这种分离还使得管理这些不同层中组件之间的依赖规则变得更加容易。

正如 Scott 所提到的，mscorlib 中似乎确实有很多“可选”的东西。这主要是由于历史原因，因为有些东西只是被其他东西需要。例如，System.IO.IsolatedStorage 需要在 mscorlib 中没有技术原因，但这正是它在 1.0 中添加的地方，在我们真正考虑此类版本控制/分层问题之前。此外，List 在 mscorlib 中是因为 mscorlib 中的其他代码需要基本列表集合。

从长远来看，我们希望尽可能减少 mscorlib 中“可选”内容的数量。通过将内容从 mscorlib 中推出，或者创建一个新的、更核心的程序集，该程序集仅包含最低限度的必要类型（例如 System.Object、System.Int32 等），以使托管代码工作。这将使我们能够灵活地向“可选”内容添加新的创新，并使创建不同的 .NET Framework SKU（例如 .NET Client Profile、Silverlight 等）变得更加容易，而无需修改运行时。

I hope this helps!

我希望这有帮助！

Thanks, Justin

谢谢，贾斯汀

回答by JaredPar

Expanding on Scott's answer.

扩展斯科特的答案。

Any given version of the CLR is highly tied to a particular version of mscorlib.dll. It is a specialDLL in very many ways. The CLR runtime requires certain types/methods be available and implements many methods defined in the actual code base. The complexity of managing this relationship is reduced by having an unbreakable link between a CLR version, and version of mscorlib.

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

回答by Hans Passant

Take a good look at any project's References node. You'll never find mscorlib.dll listed there. It is special, any compiler needs it because it contains types that are required to make the language syntax work. System.Array, System.Int32, System.String, System.Exception, etc.

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

You can write a program that doesn't have a dependency on System.dll (although it would be hard) but you can't write one that doesn't depend on mscorlib.dll

你可以编写一个不依赖 System.dll 的程序（虽然这会很难）但你不能编写一个不依赖 mscorlib.dll 的程序

回答by user39603

The mentioned native/managed thing sounds plausible, but I'm still not entirely convinced. In any case, MS seems to view mscorlib.dll as the core lib needed for the system, while System.dll contains the core functionality for programmers- which also sounds good.

提到的本地/托管的事情听起来似乎有道理，但我仍然不完全相信。无论如何，MS 似乎将 mscorlib.dll 视为系统所需的核心库，而 System.dll 包含程序员的核心功能——这听起来也不错。

I've just emailed this same question to the BCL team. If anyonecan answer... When (if?) I receive an answer, I'll post it here. Thanks for the answers so far!

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

回答by Ana Betts

This is just a guess, but mscorlib.dll probably also has some C code that's important to the CLR runtime as well as being a .NET assembly, or some mixed-mode code. System.dll is probably all managed.

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