mscorlib.dll & amp; System.dll

Question

Pourquoi MS a-t-il initialement pris la décision de maintenir ces deux bibliothèques principales distinctes? Ils avaient peut-être un problème d’évolutivité en tête, mais aujourd’hui, je ne vois jamais d’application, de quelque type que ce soit, qui n’a pas besoin des deux. Quelqu'un at-il des informations privilégiées à ce sujet? Ce n'est pas vraiment important, mais cela me préoccupe depuis des années.

PS. Je sais ce qu'il y a dans les deux bibliothèques, je connais la différence - je suis un grand fan de Reflector :) Je me demandais simplement quelle utilisation pratique avait la séparation des deux.

Answer 1

Mscorlib contient à la fois du code natif et du code managé.

Il contient notamment l'implémentation System.Object, qui doit toujours être présente pour que tout fonctionne correctement.

Il présente la particularité d'être le seul assemblage requis par le CLR pour être chargé dans chaque processus géré.

À l'origine, de nombreux éléments "facultatifs". des choses (techniquement, des choses qui ne sont pas nécessaires pour exécuter une application) ont été mises dans mscorlib car elles étaient très susceptibles d’être utilisées par tout le monde. Cela inclut des choses comme HashTable et List.

Cela a donné un coup de pouce perf. Si tout le monde veut utiliser quelque chose, il est logique de le placer dans l'assemblage que tout le monde doit charger. Ensuite, vous ne perdez pas de temps à lier plusieurs assemblages différents.

Dans System.dll, tout ce qui n’était pas digne de ce nom était digne de ce nom. d'être inclus dans mscorlib.

Cependant, cette tendance commence à s’inverser. Le CLR fait des efforts pour réduire la taille de mscorlib. Beaucoup de choses ont été supprimées pour Silverlight par exemple (pour réduire la taille du téléchargement).

Je pense qu'ils pourraient faire plus de ce genre de choses pour la V4 (et les versions ultérieures), mais je ne suis pas sûr des détails.

Answer 2

Je travaille sur l’équipe CLR / BCL et je viens de répondre à votre email. Ici, il est collé ci-dessous:

  

La réponse de Jared au débordement de pile est   à droite. mscorlib.dll est étroitement   lié à la CLR pour les raisons qu'il   mentions. Notez que mscorlib.dll   lui-même ne contient pas de code natif   (comme le suggère Scott), mais il y a   de nombreux endroits où il faut appeler   directement dans le CLR. En tant que tel, le   CLR et mscorlib doivent être versionnés   ensemble.

     

System.dll, en revanche, n'est pas   étroitement lié à la CLR (il ne   exiger des appels dans le runtime).   Nous considérons que System.dll est à un   couche supérieure à mscorlib.dll.   Avoir ces assemblées en deux   couches séparées permet plus   flexibilité, ce qui facilite la   version System.dll séparément de la   CLR / mscorlib.dll version (si nous voulions   faire cela). Nous pourrions, en théorie, faire   changements et ajouter des fonctionnalités à   System.dll sans activer le   Version CLR / mscorlib. La séparation   facilite également la gestion   règles de dépendance entre les composants de   ces différentes couches.

     

Comme le mentionne Scott, il semble que   il y a beaucoup de " optionnel " bourrer   mscorlib. Ceci est principalement pour   des raisons historiques et parce que certains   les choses sont juste nécessaires par d'autres   des choses. Par exemple, il n'y a pas   raison technique pour laquelle   System.IO.IsolatedStorage doit être   dans mscorlib, mais c’est là   arrivé à être ajouté dans 1.0, avant de   vraiment pensé à un tel   problèmes de versioning / layering. Également,   La liste est dans mscorlib car autre   le code dans mscorlib a besoin d'un   collection de liste de base.

     

À long terme, nous aimerions réduire les   montant de " optionnel " des trucs dans mscorlib   autant que possible. Soit par   pousser des choses hors de mscorlib ou   créer un nouvel assemblage plus central   qui contient juste le strict minimum   types nécessaires (par exemple, System.Object,   System.Int32, etc.) à gérer   travail de code. Cela nous donnera la   la flexibilité d'ajouter de nouvelles innovations à   le " optionnel " trucs, et le faire   plus facile de créer différents .NET   SKU de cadre (par exemple, le client .NET   Profile, Silverlight, etc.), sans   avoir à faire tourner le runtime.

J'espère que cela aide!

Merci, Justin

Answer 3

Développer la réponse de Scott.

Toute version donnée du CLR est fortement liée à une version particulière de mscorlib.dll. C’est une DLL spéciale à bien des égards. Le runtime CLR requiert la disponibilité de certains types / méthodes et implémente de nombreuses méthodes définies dans la base de code réelle. La complexité de la gestion de cette relation est réduite grâce à un lien indissociable entre une version CLR et la version de mscorlib.

Answer 4

Examinez attentivement le nœud Références de tout projet. Vous ne trouverez jamais mscorlib.dll dans la liste. Il est spécial, tout compilateur en a besoin car il contient les types nécessaires au bon fonctionnement de la syntaxe du langage. System.Array, System.Int32, System.String, System.Exception, etc.

Vous pouvez écrire un programme qui ne dépend pas de System.dll (bien que ce soit difficile), mais vous ne pouvez pas en écrire un qui ne dépend pas de mscorlib.dll

Answer 5

La chose citée comme native / gérée semble plausible, mais je ne suis toujours pas totalement convaincue. Dans tous les cas, MS semble considérer mscorlib.dll comme la bibliothèque principale nécessaire au système , alors que System.dll contient les fonctionnalités essentielles des programmeurs , ce qui est également une bonne chose.

Je viens juste d'envoyer cette même question par courrier électronique à l'équipe de la BCL. Si quelqu'un peut répondre ... Quand (si?) Je recevrai une réponse, je la posterai ici. Merci pour les réponses jusqu'à présent!

Answer 6

Ceci n’est qu’une hypothèse, mais mscorlib.dll contient probablement aussi du code C important pour le runtime CLR, ainsi qu’un assemblage .NET ou du code en mode mixte. System.dll est probablement tout géré.