mscorlib.dll & System.dll

Question

¿Por qué MS tomó originalmente la decisión de mantener estas dos librerías separadas? Quizás tenían algún problema de escalabilidad en mente, pero hoy en día nunca veo una aplicación, de ningún tipo, que no necesite ambas. ¿Alguien tiene información interna sobre esto? No es realmente importante, pero ha estado en mi mente durante años.

PS. Sé lo que hay en las dos libs, sé la diferencia. Soy un gran fan de Reflector :) Solo me pregunto qué uso práctico tiene la separación de las dos.

Answer 1

Mscorlib contiene tanto código nativo como código administrado.

Entre otras cosas, contiene la implementación de System.Object, que siempre debe estar presente para que todo funcione.

Tiene la distinción de ser el único conjunto que el CLR requiere cargar dentro de cada proceso gestionado.

Originalmente, una gran cantidad de cosas "opcionales" (cosas que técnicamente no son necesarias para ejecutar una aplicación) se pusieron en mscorlib porque eran cosas que muy probablemente fueran utilizadas por todos. Esto incluye cosas como HashTable y List.

Esto dio un impulso de perf. Si todo el mundo va a querer usar algo, entonces tiene sentido colocarlo dentro del ensamblaje que todo el mundo tiene que cargar. Entonces no tiene que perder el tiempo y enlazar un montón de conjuntos diferentes.

Las cosas en system.dll eran básicamente todo lo que no era "digno" de ser incluido en mscorlib.

Esta tendencia, sin embargo, está empezando a revertirse. El CLR está haciendo esfuerzos para reducir el tamaño de mscorlib. Se eliminaron muchas cosas para Silverlight, por ejemplo (para reducir el tamaño de descarga).

Creo que podrían estar haciendo más de este tipo de cosas para V4 (y versiones posteriores), pero no estoy seguro de los detalles.

Answer 2

Esto es sólo una suposición, pero mscorlib.dll probablemente también tenga algún código C que sea importante para el tiempo de ejecución de CLR, además de ser un ensamblado .NET o algún código de modo mixto. System.dll es probablemente todo administrado.

Answer 3

Eche un vistazo al nodo Referencias de cualquier proyecto. Nunca encontrarás mscorlib.dll allí. Es especial, cualquier compilador lo necesita porque contiene los tipos necesarios para que la sintaxis del lenguaje funcione. System.Array, System.Int32, System.String, System.Exception, etc.

Puede escribir un programa que no tenga una dependencia en System.dll (aunque sería difícil) pero no puede escriba uno que no dependa de mscorlib.dll

Answer 4

La cosa nativa/administrada mencionado parece plausible, pero aún no estoy del todo convencido. En cualquier caso, MS parece ver mscorlib.dll como la biblioteca central necesaria para el sistema , mientras que System.dll contiene la funcionalidad principal para los programadores , que también suena bien.

Acabo de enviar esta misma pregunta por correo electrónico al equipo de BCL. Si alguien puede responder ... ¿Cuándo (si?) Recibo una respuesta, la publicaré aquí. ¡Gracias por las respuestas hasta ahora!

Answer 5

Expandiendo la respuesta de Scott.

Cualquier versión del CLR está estrechamente vinculada a una versión particular de mscorlib.dll. Es una DLL especial de muchas maneras. El tiempo de ejecución de CLR requiere que ciertos tipos/métodos estén disponibles e implementa muchos métodos definidos en la base de código real. La complejidad de administrar esta relación se reduce al tener un enlace irrompible entre una versión de CLR y una versión de mscorlib.

Answer 6

Trabajo en el equipo de CLR/BCL y acabo de responder a su correo electrónico. Aquí se pega a continuación:

La respuesta de Jared en Desbordamiento de pila es justo en adelante. mscorlib.dll está estrechamente vinculado al CLR por las razones que menciona . Tenga en cuenta que mscorlib.dll no contiene ningún código nativo (como sugiere Scott), pero hay en muchos lugares donde debe llamar al directamente en el CLR. Como tal, el CLR y mscorlib deben tener la versión juntas.

System.dll, por otro lado, no es estrechamente vinculado al CLR (no requiere ninguna llamada en el tiempo de ejecución). Consideramos que System.dll está en una capa superior que mscorlib.dll. Tener estas asambleas en dos capas separadas permite una mayor flexibilidad , por lo que es la versión más fácil de system.dll por separado de la versión CLR/mscorlib.dll (si queríamos para hacerlo). Podría, en teoría, realizar cambios en y agregar funcionalidad a System.dll sin acelerar la versión CLR/mscorlib. La separación también facilita la administración de las reglas de dependencia entre los componentes en estas diferentes capas.

Como dice Scott, parece que hay un montón de cosas "opcionales" en mscorlib. Esto es principalmente para razones históricas y porque algunas cosas solo son necesarias por otras cosas . Por ejemplo, no hay ninguna razón técnica por System.IO.IsolatedStorage necesita ser en mscorlib, pero eso es sólo donde pasó a ser añadido en 1.0, antes de que pensado en tales de versiones/preocupaciones de estratificación. Además, la lista está en mscorlib porque el otro código en mscorlib necesita una colección de lista básica .

A largo plazo nos gustaría reducir la cantidad de "opcional" en mscorlib tanto como sea posible. Ya sea por empujar cosas de mscorlib o la creación de un nuevo y más núcleo, el conjunto que solo contiene los desnudos mínimo tipos necesarios (por ejemplo System.Object, System.Int32, etc.) para hacer el trabajo logrado código. Esto nos dará la flexibilidad para agregar nuevas innovaciones a las cosas "opcional", y que sea más fácil crear diferente .NET Framework SKU (por ejemplo, el perfil de cliente .NET , Silverlight, etc.), sin tener para acelerar el tiempo de ejecución.

Espero que esto ayude!

Gracias, Justin