mscorlib.dll & System.dll

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

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

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

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

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

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

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

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

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

Ответ Джареда о переполнении стека прямо. 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, прежде чем мы действительно думали о таких проблемах с версиями / расслоением. Кроме того, List находится в mscorlib, потому что другой код в mscorlib нуждается в основной коллекции списков.

В долгосрочной перспективе мы хотели бы как можно больше уменьшить количество «факультативных» материалов в mscorlib. Либо выталкивая материал из mscorlib, либо создавая новую, более основную сборку, которая содержит только минимально необходимые типы (например, System.Object, System.Int32 и т. Д.), Чтобы работать с управляемым кодом. Это даст нам гибкость для добавления новых нововведений в «факультативные» вещи и упростит создание различных SKU .NET Framework (например, .NET Client Profile, Silverlight и т. Д.) Без необходимости обновления среды выполнения.

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

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

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

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

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

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

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

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

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