mscorlib.dll & System.dll

Question

Warum MS ursprünglich die Entscheidung, diese beiden separaten Kern Libs aufrecht zu erhalten? Vielleicht hatte sie im Sinne etwas Skalierbarkeit Problem, aber heute sehe ich nie eine Anwendung, jegliche Art, die nicht beide benötigt. Hat jemand eine Insider-Informationen zu diesem Thema? Es ist nicht wirklich wichtig, aber seit Jahren in meinem Kopf gewesen.

PS. Ich weiß, was in den beiden libs ist, ich kenne den Unterschied - ich bin ein großer Fan von Reflector :) Nur frage mich, was die praktische Anwendung der Trennung der beiden hat.

Answer 1

Mscorlib tut enthält sowohl native und verwaltete Code.

Unter anderem enthält sie die System.Object Implementierung, die immer vorhanden sein muss, um für alles zu arbeiten.

Es hat die Unterscheidung der einzige Montage ist, dass die CLR innerhalb jedem verwalteten Prozess geladen werden muss.

Ursprünglich viel „optional“ Sachen (Dinge, die technisch nicht eine App auszuführen sind erforderlich) wurde in mscorlib, weil sie die Dinge, die sehr wahrscheinlich waren von jedermann genutzt werden. Dazu gehören Dinge wie HashTable und Liste.

Dies ergab einen perf Schub. Wenn jeder wollen, geht etwas zu verwenden, dann macht es Sinn, es in der Versammlung zu setzen, dass jeder zu laden hat. Dann müssen Sie nicht Zeit zu gehen und Bindung eine ganze Reihe von verschiedenen Baugruppen verschwenden.

Das Zeug in system.dll im Grunde alles, was ist, die nicht "würdig" war in mscorlib enthalten ist.

Dieser Trend jedoch beginnt, umgekehrt werden. Die CLR bemüht sich die Größe von mscorlib zu reduzieren. Eine Menge Sachen wurde für Silverlight zum Beispiel entfernt (Download-Größe zu reduzieren).

Ich denke, sie könnten für V4 mehr von dieser Art von Sachen tun (und spätere Versionen), aber ich bin mir nicht sicher über die Details.

Answer 2

Ich arbeite auf der CLR / BCL-Team und beantworten einfach Ihre E-Mail. Hier wird eingefügt unter:

  

Jared Antwort auf Stack-Überlauf ist   direkt am. mscorlib.dll ist fest   aus den Gründen, auf die CLR gebunden er   erwähnt. Beachten Sie, dass mscorlib.dll   selbst enthält keinen nativen Code   (Als Scott schon sagt), aber es gibt   viele Orte, wo es braucht, rufen   direkt in die CLR. Als solches ist das   CLR und mscorlib muss versioniert werden   zusammen.

     

System.dll auf der anderen Seite ist nicht   fest an die CLR gebunden (es funktioniert nicht   erfordern keine Anrufe in die Laufzeit).   Wir betrachten System.dll bei einem sein   höhere Schicht als mscorlib.dll.   Nachdem diese Anordnungen in zwei   getrennte Schichten ermöglicht mehr   Flexibilität, so dass es leichter zu   Version System.dll getrennt von der   CLR / mscorlib.dll-Version (wenn wir wollten   dies zu tun). Wir konnten in der Theorie machen   Änderungen und erweitern die Funktionalität   System.dll ohne die revving   CLR / mscorlib Version. Die Trennung   macht es auch einfacher zu verwalten   Abhängigkeitsregeln zwischen den Komponenten in   diese verschiedenen Schichten.

     

Wie Scott erwähnt, scheint es so, wie   es gibt eine Menge von „optional“ Sachen in   mscorlib. Dies ist vor allem für   historischen Gründen und weil einige   Dinge werden nur von anderen benötigt   Dinge. Zum Beispiel gibt es keine   technischer Grund, warum   System.IO.IsolatedStorage muss sein   in mscorlib, aber das ist, wo es nur   passiert werden in 1,0, zugegeben, bevor wir   wirklich über solche   Versionierung / Schichtung betrifft. Ebenfalls,   Liste ist in mscorlib weil andere   Code in mscorlib hat ein Bedürfnis für eine   Grundliste Sammlung.

     

Langfristig möchten wir das reduzieren,   Menge „optional“ Sachen in mscorlib   so viel wie möglich. entweder durch   Schieben Sachen aus mscorlib oder   eine neue, Kern zu schaffen, die Montage   dass enthält nur das Nötigste   erforderliche Typen (z.B. System.Object,   System.Int32, etc.) machen verwaltet   Code zu arbeiten. Dies gibt uns die   Flexibilität, neue Innovationen in den   die „optional“ Sachen, und es machen   leichter unterschiedliche .NET erstellen   Framework-SKUs (zum Beispiel des .NET-Client   Profil, Silverlight, etc.), ohne   mit der Laufzeit rev.

Ich hoffe, das hilft!

Danke, Justin

Answer 3

Die Erweiterung auf Scotts Antwort.

Jede gegebene Version der CLR ist stark auf eine bestimmte Version von mscorlib.dll gebunden. Es ist ein besondere DLL in sehr viele Möglichkeiten. Die CLR-Laufzeit erfordert bestimmte Arten / Methoden zur Verfügung und viele Methoden implementiert in der eigentlichen Code-Basis definiert. Die Komplexität dieser Beziehung Verwaltung wird erreicht, indem eine unzerbrechliche Verbindung zwischen einer CLR-Version und die Version von mscorlib reduziert.

Answer 4

Nehmen Sie einen guten Blick auf jeden Knoten Verweise des Projekts. Sie werden nie dort mscorlib.dll aufgelistet. Es ist etwas Besonderes, jeder Compiler es braucht, weil es Typen enthält, die die Sprachsyntax Arbeit machen erforderlich sind. System.Array, System.Int32, System.String, System.Exception, etc.

Sie können ein Programm schreiben, das nicht eine Abhängigkeit von System.dll hat (obwohl es schwer sein würde), aber sie kann man nicht schreiben, die nicht auf mscorlib.dll abhängt

Answer 5

Die genannten nativen / verwaltet, was klingt plausibel, aber ich bin immer noch nicht ganz überzeugt. Auf jeden Fall scheint MS mscorlib.dll als Kern lib für das System , während System.dll enthält die Kernfunktionalität für Programmierer benötigt zu sehen - was auch gut klingt.

Ich habe per E-Mail nur diese gleiche Frage an das BCL-Team. Wenn jemand beantworten ... Wenn (wenn?) Ich eine Antwort erhalten, werde ich es hier posten. Danke für die Antworten bisher!

Answer 6

Das ist nur eine Vermutung, aber Mscorlib.dll wahrscheinlich hat auch einig C-Code, der als eine .NET-Assembly als auch auf die CLR Laufzeit wichtig ist, oder einig Mixed-Mode-Code. System.dll wird wahrscheinlich alle verwaltet werden.