mscorlib.dll & amp; System.dll

Question

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

PS. Sé lo que hay en las dos librerías, sé la diferencia: soy un gran fanático del Reflector :) Solo me pregunto qué uso práctico tiene la separación de los 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 ensamblaje que el CLR requiere que se cargue dentro de cada proceso administrado.

Originalmente, una gran cantidad de " opcional " Las cosas (cosas que técnicamente no se requieren para ejecutar una aplicación) se colocaron en mscorlib porque eran cosas que era muy probable que fueran utilizadas por todos. Esto incluye cosas como HashTable y List.

Esto dio un impulso de perf. Si todos van a querer usar algo, entonces tiene sentido colocarlo dentro del ensamblaje que todos tienen que cargar. Entonces no tiene que perder tiempo y atar un montón de ensamblajes diferentes.

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

Sin embargo, esta tendencia está comenzando 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 la 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

Trabajo en el equipo de CLR / BCL y acabo de responder tu correo electrónico. Aquí está pegado abajo:

  

La respuesta de Jared en Stack Overflow es   tocar el asunto exacto. mscorlib.dll está bien   obligado a la CLR por las razones que   menciones Tenga en cuenta que mscorlib.dll   En sí no contiene ningún código nativo   (como Scott sugiere), pero hay   muchos lugares donde necesita llamar   directamente en el CLR. Como tal, el   CLR y mscorlib deben ser versionados   juntos.

     

System.dll por otro lado no es   estrechamente ligado al CLR (no lo hace   requerir cualquier llamada en el tiempo de ejecución).   Consideramos que System.dll está en un   capa más alta que mscorlib.dll.   Teniendo estos montajes en dos   capas separadas permite más   flexibilidad, haciendo más fácil   versión System.dll por separado de la   Versión CLR / mscorlib.dll (si quisiéramos   para hacerlo). Podríamos, en teoría, hacer   Cambia y agrega funcionalidad a   System.dll sin revivir el   Versión CLR / mscorlib. La separación   También hace que sea más fácil de manejar   reglas de dependencia entre componentes en   estas diferentes capas.

     

Como menciona Scott, parece que   hay una gran cantidad de " opcional " cosas en   mscorlib. Esto es principalmente para   razones históricas y porque algunos   Las cosas solo son necesarias por otro   cosas. Por ejemplo, no hay   razón técnica por la cual   System.IO.IsolatedStorage necesita ser   en mscorlib, pero eso es justo donde   Pasó a ser agregado en 1.0, antes de que nosotros   realmente pensado en tales   Preocupaciones de versiones / capas. También,   La lista está en mscorlib porque otros   código en mscorlib tiene una necesidad de una   colección básica de la lista.

     

A largo plazo nos gustaría reducir el   cantidad de " opcional " cosas en mscorlib   cuanto más se pueda. Ya sea por   empujando cosas fuera de mscorlib o   Creando un nuevo, más núcleo, montaje.   que solo contiene el mínimo   tipos necesarios (por ejemplo, System.Object,   System.Int32, etc.) para hacer gestionados.   código de trabajo. Esto nos dará la   flexibilidad para añadir nuevas innovaciones a   el " opcional " cosas, y hazlo   Más fácil crear diferentes .NET   SKU de Framework (por ejemplo, el cliente .NET)   Perfil, Silverlight, etc.), sin   Tener que acelerar el tiempo de ejecución.

Espero que esto ayude!

Gracias, Justin

Answer 3

Ampliando la respuesta de Scott.

Cualquier versión dada del CLR está altamente 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 inquebrantable entre una versión CLR y una versión de mscorlib.

Answer 4

Observe detenidamente el nodo Referencias de cualquier proyecto. Nunca encontrarás mscorlib.dll listado allí. Es especial, cualquier compilador lo necesita porque contiene tipos que se requieren para hacer 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 escribir uno que no dependa de mscorlib.dll

Answer 5

Lo mencionado nativo / administrado parece plausible, pero todavía 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 al equipo de BCL. Si cualquiera puede responder ... Cuando (si?) Recibo una respuesta, la publicaré aquí. ¡Gracias por las respuestas hasta ahora!

Answer 6

Esto es solo una conjetura, 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 gestionado.