mscorlib.dll & System.dll

Question

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

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

Answer 1

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

Ответ Джареда о переполнении стека: Право на. mscorlib.dll тесно связан с ЦПР по причинам, которые он упоминает. Обратите внимание, что 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 Профиль, Silverlight и др.), Без необходимо изменить время выполнения.

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

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

Answer 2

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

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

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

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

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

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

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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