Mscorlib.dll и System.dll

Это всего лишь предположение, но mscorlib.dll, вероятно, также имеет некоторый код C, который важен для среды выполнения CLR, а также является сборкой .NET или некоторым кодом смешанного режима. System.dll, наверное, все управляется.

Внимательно посмотрите на узел Ссылки любого проекта. Вы никогда не найдете там mscorlib.dll. Он особенный, он нужен любому компилятору, потому что он содержит типы, необходимые для работы синтаксиса языка. System.Array, System.Int32, System.String, System.Exception и т. д.

Вы можете написать программу, не зависящую от System.dll (хотя это было бы сложно), но вы не можете написать программу, которая не зависит от mscorlib.dll.

Mscorlib действительно содержит как собственный, так и управляемый код.

Помимо прочего, он содержит реализацию System.Object, которая всегда должна присутствовать, чтобы все работало.

Он отличается тем, что является единственной сборкой, которую CLR требует загружать в каждый управляемый процесс.

Первоначально в mscorlib было помещено множество «необязательных» вещей (вещей, которые технически не требуются для запуска приложения), потому что они с большой вероятностью будут использоваться всеми. Сюда входят такие вещи, как HashTable и List.

Это дало прирост производительности. Если каждый хочет что-то использовать, имеет смысл поместить это в сборку, которую все должны загрузить. Тогда вам не придется тратить время на связывание целой кучи разных сборок.

Материал в system.dll был в основном всем, что не было «достойным» включения в mscorlib.

Однако эта тенденция начинает меняться. CLR пытается уменьшить размер mscorlib. Например, для Silverlight было удалено много всего (для уменьшения размера загрузки).

Я думаю, что они могут делать больше подобных вещей для V4 (и более поздних версий), но я не уверен в деталях.

Упомянутая родная / управляемая вещь звучит правдоподобно, но я все еще не совсем уверен. В любом случае MS, похоже, рассматривает mscorlib.dll как базовую библиотеку, необходимую для система, в то время как System.dll содержит основные функции для программисты, что также неплохо звучит.

Я только что отправил по электронной почте тот же вопрос команде BCL. Если кто-нибудь может ответить ... Когда (если?) Я получу ответ, я отправлю его сюда. Спасибо за ответы!

Расширение ответа Скотта.

Любая данная версия CLR сильно привязана к конкретной версии mscorlib.dll. Во многих отношениях это библиотека DLL специальный. Среда выполнения CLR требует наличия определенных типов / методов и реализует множество методов, определенных в фактической базе кода. Сложность управления этими отношениями снижается за счет наличия неразрывной связи между версией CLR и версией mscorlib.

Я работаю в команде 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.

Надеюсь, это поможет!

Спасибо, Джастин