Qual è il punto di System.IO.dll?

Question

Per quanto ne so, la maggior parte dei tipi di seguito sono ora, e sono sempre stati, definiti in mscorlib e/o System.dll.

Tuttavia, guardando nelle directory framework v4 (ho 4.5 installato, non sono sicuro se esiste anche in Vanilla v4), trovo un assembly chiamato System.IO.dll.

Esaminandolo nel riflettore, non riesco a vedere alcun codice effettivo. Tutto quello che posso trovare sono le seguenti voci:

[assembly: TypeForwardedTo(typeof(BinaryReader))] 
[assembly: TypeForwardedTo(typeof(BinaryWriter))] 
[assembly: TypeForwardedTo(typeof(EndOfStreamException))] 
[assembly: TypeForwardedTo(typeof(FileNotFoundException))] 
[assembly: TypeForwardedTo(typeof(InvalidDataException))] 
[assembly: TypeForwardedTo(typeof(IOException))] 
[assembly: TypeForwardedTo(typeof(MemoryStream))] 
[assembly: TypeForwardedTo(typeof(SeekOrigin))] 
[assembly: TypeForwardedTo(typeof(Stream))] 
[assembly: TypeForwardedTo(typeof(StreamReader))] 
[assembly: TypeForwardedTo(typeof(StreamWriter))] 
[assembly: TypeForwardedTo(typeof(StringReader))] 
[assembly: TypeForwardedTo(typeof(StringWriter))] 
[assembly: TypeForwardedTo(typeof(TextReader))] 
[assembly: TypeForwardedTo(typeof(TextWriter))] 

Tutto punta al mscorlib (penso, non ho controllato tutti). Ho dato un'occhiata in giro e non riesco a vedere alcuna versione di framework (ad esempio silverlight, compact, ecc.) In cui questi tipi non sono in mscorlib. Quindi, qualcuno sa perché questo assemblaggio esiste (e perché ora)?

Answer 1

Hai trovato un gruppo di riferimento . Può sembrare strano, dal momento che non si usa assolutamente un assembly di riferimento in un progetto .NET che abbia come destinazione .NET> = 4.0. Normalmente li si ottiene dalla directory C: \ Programmi (x86) \ Reference Assembly sulla macchina di sviluppo. Ma questo non è l'unico scenario in cui viene utilizzato un compilatore. Si utilizza anche un compilatore quando si utilizza System.CodeDom nel programma o dipende dalla serializzazione XML.

Specifiche su System.CodeDom e serializzazione XML è che il compilatore viene eseguito sul computer dell'utente. E che non puoi scegliere come target una versione specifica di .NET Framework. Il computer dell'utente non ha i pacchetti di targeting della tua macchina. Quindi ottiene che qualsiasi versione sia installata sulla macchina. I file in C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 contengono gli assembly di riferimento corrispondenti alla versione installata. Se la macchina viene aggiornata con un'altra versione di .NET 4.x, anche quegli assembly di riferimento vengono aggiornati.

Non è l'unico scenario possibile, è probabile che vengano utilizzati anche quando si costruisce dalla riga di comando. O su un server di build e ha deciso di non pagare per una licenza VS, pessima idea. O in un comando di ILMerge, un'idea eccessivamente cattiva. Questi scenari sono molto più problematici. Funziona bene purché il gruppo costruito rimanga sulla stessa macchina. Ma non se viaggiano in un altro computer, uno con una versione di framework diversa installata. Ciò può produrre eccezioni runtime abbastanza misteriose, evidenti in this Q+A.

System.IO.dll è abbastanza esotico. Ne avrai solo bisogno quando eseguirai System.CodeDom con un riferimento a un assembly PCL. Il suo ruolo principale è quello di nascondere le dichiarazioni, il tipo che non dovrebbe essere utilizzato nel profilo selezionato. Lo spazio dei nomi System.IO deve essere nascosto perché questi tipi non possono essere utilizzati quando si sceglie WinRT. Ma altrimenti il ​​motivo per cui non contiene alcun tipo, [TypeForwardedTo] dice al compilatore che il tipo è supportato su una macchina desktop e per cercare la dichiarazione altrove, mscorlib.dll