mscorlib.dll & System.dll

Question

Pourquoi MS à l'origine de prendre la décision de maintenir ces deux centrales distinctes libs? Peut-être qu'ils avaient un problème d'évolutivité à l'esprit, mais de nos jours je ne vois jamais une application, de tout type, qui n'a pas besoin des deux. Quelqu'un a une information à l'intérieur? Ce n'est pas vraiment important, mais dans ma tête depuis des années.

PS. Je sais ce qui est dans les deux libs, je sais faire la différence - je suis un grand fan de Réflecteur :) je me demandais ce que l'utilisation pratique de la séparation des deux.

Answer 1

Je travaille sur le CLR/BCL équipe et viens de répondre à votre e-mail. Ici, il est collé ci-dessous:

Jared sa réponse sur un Débordement de Pile est à droite sur. 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 Scott suggère), mais il y a de nombreux endroits où il a besoin de faire appel directement dans le CLR. En tant que tel, l' CLR et mscorlib doit être versionné ensemble.

System.dll sur l'autre main n'est pas étroitement lié à la CLR (il n'a pas exiger de tous les appels dans le moteur d'exécution). Nous considérons System.dll pour être à l' la couche supérieure de mscorlib.dll. Ces assemblées en deux séparer les couches permet plus de la flexibilité, la rendant plus facile à version System.dll séparément de l' CLR/mscorlib.dll version (si nous voulions pour ce faire). On pourrait, en théorie, faire des modifications et ajouter des fonctionnalités à Système.dll sans montée en régime de la CLR/mscorlib version. La séparation aussi rend plus facile à gérer règles de dépendances entre les composants de ces différentes couches.

Comme Scott mentionne, il semble y avoir il y a beaucoup de "facultatif" des trucs dans mscorlib. C'est principalement pour des raisons historiques et parce que certains les choses sont requises par d'autres les choses. Par exemple, il n'y a pas pour des raisons techniques Système.IO.IsolatedStorage doit être dans mscorlib, mais c'est juste là où il qui est arrivé à être ajouté en 1.0, avant de nous vraiment réfléchi à ces gestion des versions/stratification des préoccupations. Aussi, La liste est dans mscorlib parce que d'autres code dans mscorlib a un besoin pour un liste de base de la collection.

À Long terme, nous aimerions réduire la montant de "facultatif" des trucs dans mscorlib autant que possible. Soit par poussant les choses de mscorlib ou la création d'une nouvelle, plus core, assemblée qui ne contient que le strict minimum types nécessaires (p. ex. Système.Objet, Système.Int32, etc.) pour faire gérés le code du travail. Cela nous donnera la possibilité d'ajouter de nouvelles innovations le "facultatif" choses", et de le rendre plus facile de créer différents .NET Cadre de Références (par exemple, l' .NET Client De profil, Silverlight, etc.), sans dans les tours le moteur d'exécution.

J'espère que cela aide!

Merci, Justin

Answer 2

Mscorlib ne contient le code géré et natif.

Parmi d'autres choses, il contient le Système.Implémentation de l'objet, qui doit toujours être présente dans l'ordre pour que tout fonctionne.

Il a la distinction d'être la seule assemblée que le CLR, qui nécessite d'être chargé à l'intérieur de chaque processus de gestion.

À l'origine, beaucoup de "facultatif" trucs (des choses qui, techniquement, ne sont pas requis pour exécuter une application) a été mis en mscorlib parce qu'ils étaient des choses qui étaient très susceptibles d'être utilisés par tout le monde. Cela inclut des choses comme la table de hachage et de la Liste.

Cela a donné une perf coup de pouce. Si tout le monde va vouloir utiliser quelque chose, alors il est logique de le mettre à l'intérieur de l'assemblée pour que tout le monde a à charge. Ensuite, vous n'avez pas perdre de temps à aller et la reliure d'un tas de différents assemblages.

Les trucs en system.dll était fondamentalement tout ce qui n'était pas "digne" d'être inclus dans mscorlib.

Toutefois, cette tendance est en train de s'inverser. Le CLR est de faire des efforts pour réduire la taille de mscorlib. Beaucoup de choses ont été supprimés pour Silverlight par exemple (pour réduire la taille de téléchargement).

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

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 native / administrée mentionnée semble plausible, mais je ne suis toujours pas totalement convaincue. Dans tous les cas, MS semble considérer mscorlib.dll comme la librairie principale nécessaire au système , tandis que System.dll contient les fonctionnalités essentielles des programmeurs , ce qui semble également bon.

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 reçois une réponse, je la posterai ici. Merci pour les réponses fournies jusqu'ici!