Mscorlib.dll & System.dll

Почему MS первоначально принимала решение поддерживать эти две отдельные базовые библиотеки? Возможно, у них была проблема с масштабируемостью, но в настоящее время я никогда не вижу приложения любого типа, которое не нуждается в обоих. Кто-нибудь имеет какую-либо внутреннюю информацию об этом? Это не очень важно, но было на мой взгляд в течение многих лет.

PS. Я знаю, что в двух libs, я знаю разницу - я большой поклонник Reflector:) Просто интересно, какое практическое использование разделение этих двух.

Ответ 1

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

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

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

Первоначально в "mscorlib" было добавлено много "необязательного" материала (вещи, которые технически не требуются для запуска приложения), потому что это были вещи, которые, вероятно, были бы использованы всеми. Это включает в себя такие вещи, как HashTable и List.

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

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

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

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

Ответ 2

Я работаю над командой CLR/BCL и просто ответил на вашу электронную почту. Здесь он вставлен ниже:

Ответ Jared на переполнение стека Право на. 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. Framework SKU (например,.NET Client Профиль, Silverlight и т.д.), Без необходимо обновить время выполнения.

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

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

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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