mscorlib.dll & amp; System.dll

Question

Perché MS inizialmente ha deciso di mantenere queste due librerie core separate? Forse avevano in mente qualche problema di scalabilità, ma al giorno d'oggi non vedo mai un'applicazione, di alcun tipo, che non abbia bisogno di entrambi. Qualcuno ha informazioni privilegiate su questo? Non è molto importante, ma è stato nella mia mente per anni.

PS. So cosa c'è nelle due librerie, conosco la differenza: sono un grande fan di Reflector :) Mi chiedo solo quale uso pratico abbia la separazione dei due.

Answer 1

Mscorlib contiene sia codice nativo che gestito.

Tra le altre cose contiene l'implementazione System.Object, che deve essere sempre presente affinché tutto funzioni.

Ha la particolarità di essere l'unico assembly che il CLR richiede di essere caricato all'interno di ogni processo gestito.

Inizialmente, molti "opzionali" cose (cose che tecnicamente non sono necessarie per eseguire un'app) sono state messe in mscorlib perché erano cose che molto probabilmente sarebbero state usate da tutti. Questo include cose come HashTable e List.

Questo ha dato una spinta perfetta. Se tutti vogliono usare qualcosa, allora ha senso metterlo all'interno dell'assieme che tutti devono caricare. Quindi non devi perdere tempo andando e vincolando un sacco di gruppi diversi.

Le cose in system.dll erano praticamente tutto ciò che non era "degno". di essere incluso in mscorlib.

Questa tendenza, tuttavia, sta iniziando a invertirsi. Il CLR sta compiendo sforzi per ridurre le dimensioni di mscorlib. Ad esempio Silverlight ha rimosso molte cose (per ridurre le dimensioni del download).

Penso che potrebbero fare più cose del genere per V4 (e versioni successive) ma non sono sicuro dei dettagli.

Answer 2

Lavoro nel team CLR / BCL e ho appena risposto alla tua email. Qui è incollato di seguito:

  

La risposta di Jared su Stack Overflow è   giusto. mscorlib.dll è strettamente   vincolato al CLR per i motivi che lui   menzioni. Si noti che mscorlib.dll   di per sé non contiene alcun codice nativo   (come suggerisce Scott), ma ci sono   molti posti dove deve chiamare   direttamente nel CLR. Come tale, il   CLR e mscorlib devono essere versionati   insieme.

     

System.dll invece non lo è   strettamente legato al CLR (non lo fa   richiedere eventuali chiamate nel runtime).   Consideriamo System.dll come a   livello superiore rispetto a mscorlib.dll.   Avere queste assemblee in due   livelli separati consentono di più   flessibilità, rendendolo più facile   versione System.dll separatamente dal   Versione CLR / mscorlib.dll (se volevamo   fare così). Potremmo, in teoria, fare   modifiche e aggiungere funzionalità a   System.dll senza revocare il file   Versione CLR / mscorlib. La separazione   inoltre semplifica la gestione   regole di dipendenza tra i componenti in   questi diversi livelli.

     

Come dice Scott, sembra   c'è un sacco di " opzionale " roba dentro   mscorlib. Questo è principalmente per   ragioni storiche e perché alcune   le cose sono necessarie solo agli altri   cose. Ad esempio, non c'è   motivo tecnico perché   System.IO.IsolatedStorage deve essere   in mscorlib, ma è proprio lì   è capitato di essere aggiunto in 1.0, prima di noi   ci ho pensato davvero   problemi di versioning / stratificazione. Anche,   L'elenco è in mscorlib perché altro   il codice in mscorlib ha bisogno di a   raccolta di elenchi di base.

     

A lungo termine vorremmo ridurre il   importo di "opzionale" cose in mscorlib   per quanto possibile. Mediante   spingendo roba da mscorlib o   creando un nuovo, più core, assembly   che contiene solo il minimo indispensabile   tipi necessari (ad es. System.Object,   System.Int32, ecc.) Da gestire   lavoro del codice. Questo ci darà il   flessibilità per aggiungere nuove innovazioni a   il " opzionale " roba e ce la facciamo   più facile creare diversi .NET   SKU Framework (ad es. Il client .NET   Profilo, Silverlight, ecc.), Senza   dover rev il runtime.

Spero che questo aiuti!

Grazie, Justin

Answer 3

Ampliamento della risposta di Scott.

Ogni versione del CLR è fortemente legata a una versione particolare di mscorlib.dll. È una speciale DLL in molti modi. Il runtime CLR richiede che siano disponibili determinati tipi / metodi e implementa molti metodi definiti nella base di codice effettiva. La complessità della gestione di questa relazione è ridotta dall'avere un legame indissolubile tra una versione CLR e la versione di mscorlib.

Answer 4

Dai un'occhiata al nodo Riferimenti di qualsiasi progetto. Non troverai mai mscorlib.dll elencato lì. È speciale, qualsiasi compilatore ne ha bisogno perché contiene i tipi necessari per far funzionare la sintassi del linguaggio. System.Array, System.Int32, System.String, System.Exception, ecc.

Puoi scrivere un programma che non ha una dipendenza da System.dll (anche se sarebbe difficile) ma non puoi scriverne uno che non dipende da mscorlib.dll

Answer 5

La cosa nativa / gestita menzionata sembra plausibile, ma non sono ancora del tutto convinto. In ogni caso, MS sembra vedere mscorlib.dll come la libreria di base necessaria per il sistema , mentre System.dll contiene le funzionalità di base per programmatori - che suona bene.

Ho appena inviato questa stessa domanda al team BCL. Se qualcuno può rispondere ... Quando (se?) Ricevo una risposta, la posterò qui. Grazie per le risposte finora!

Answer 6

Questa è solo un'ipotesi, ma mscorlib.dll probabilmente ha anche un codice C importante per il runtime CLR, oltre ad essere un assembly .NET o un codice in modalità mista. System.dll è probabilmente tutto gestito.