mscorlib.dll & Sistema.DLL

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

La respuesta de Jared en Stack Overflow es muy bien. mscorlib.dll es apretado vinculado al CLR por las razones que mencionar. Tenga en cuenta que mscorlib.DLL 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 junto.

Sistema.dll en el otro la mano no es fuertemente atado al CLR (no lo hace require any calls into the runtime). Consideramos el Sistema.dll para estar en un capa más alta que mscorlib.DLL. Tener estas asambleas en dos capas separadas permite más flexibilidad, por lo que es más fácil sistema de versiones.dll por separado de la CLR / mscorlib.versión dll (si quisiéramos haciéndolo). Podríamos, en teoría, hacer cambios y añadir funcionalidad a Sistema.dll sin acelerar el Versión CLR / mscorlib. Separación también hace que sea más fácil de administrar reglas de dependencia entre componentes en estas diferentes capas.

Como Scott menciona, parece que hay un montón de cosas "opcionales" en mscorlib. Esto es principalmente para razones históricas y porque algunos las cosas solo son necesarias por otros cosa. Por ejemplo, no hay razones técnicas System. IO. IsolatedStorage necesita ser en mscorlib, pero ahí es donde pasó a ser añadido en 1.0, antes de que realmente pensé en tales preocupaciones de versionado / estratificación. También, Lista está en mscorlib porque otros código en mscorlib tiene una necesidad de un colección de listas básicas.

A largo plazo nos gustaría reducir el cantidad de cosas" opcionales " en mscorlib tanto como sea posible. Ya sea por empujando cosas fuera de mscorlib o creación de un nuevo, más núcleo, asamblea que solo contiene el mínimo tipos necesarios (por ejemplo, Sistema.Objeto, System. Int32, etc.) para hacer gestionado código de trabajo. Esto nos dará la flexibilidad para añadir nuevas innovaciones a las cosas" opcionales", y lo hacen más fácil de 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

Ampliando la respuesta de Scott.

Cualquier versión dada del CLR está muy ligada 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 manejar esta relación se reduce al tener un vínculo irrompible entre una versión de CLR y la versión de mscorlib.

Eche un buen vistazo al nodo de referencias de cualquier proyecto. Nunca encontrarás a Mscorlib.dll listado allí. Es especial, cualquier compilador lo necesita porque contiene tipos que son necesarios para que la sintaxis del lenguaje funcione. Sistema.Array, Sistema. Int32, Sistema.Cadena, Sistema.Excepción, etc.

Puede escribir un programa que no tenga una dependencia del Sistema.dll (aunque sería difícil) pero no puedes escribir uno que no dependa de mscorlib.dll

La mencionada cosa nativa/administrada suena plausible, pero todavía no estoy del todo convencido. En cualquier caso, MS parece ver mscorlib.dll como el núcleo lib necesario para el sistema , while System.dll contiene la funcionalidad principal para programadores - que también suena bien.

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

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