¿Cuál es el punto de System.IO.dll?

Question

Por lo que yo sé, la mayoría de los tipos siguientes son ahora, y siempre han sido, definido en mscorlib y/o System.dll.

Sin embargo, al mirar en los directorios marco v4 (tengo 4.5 instalado, no estoy seguro si también existe en Vanilla v4), me parece un montaje llamado System.IO.dll.

examinarla en el reflector, no puedo ver ningún código real. Todo lo que puedo encontrar son las siguientes entradas:

[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))] 

Todo apunta de nuevo a mscorlib (creo, no han comprobado todos ellos). He echado un vistazo y no puedo ver ninguna versión de framework (por ejemplo, silverlight, compact, etc.) donde estos tipos no están en mscorlib. Entonces, ¿alguien sabe por qué existe esta asamblea (y por qué ahora)?

Answer 1

Se encontró que una estructura referencia. Eso puede sonar extraño, ya que definitivamente no usa un ensamblaje de referencia de este tipo en un proyecto .NET que apunta a .NET> = 4.0. Normalmente los obtiene del directorio C: \ Program Files (x86) \ Reference Assemblies en su máquina de desarrollo. Pero ese no es el único escenario en el que se utiliza un compilador. También utiliza un compilador cuando utiliza System.CodeDom en su programa o depende de la serialización de XML.

específica sobre System.CodeDom y la serialización XML es que el compilador se ejecuta en la máquina del usuario. Y que no puede dirigirse a una versión específica de .NET Framework. La máquina de su usuario no tiene los paquetes de orientación que tiene su máquina. Por lo tanto, obtiene la versión que esté instalada en la máquina. Los archivos en C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 contienen los ensamblados de referencia que coinciden con la versión instalada. Si la máquina se actualiza con otra versión de .NET 4.x, esos conjuntos de referencia también se actualizan.

No es el único escenario posible, es probable que también se va a utilizar cuando se construye desde la línea de comandos. O en un servidor de compilación y decidió no pagar una licencia VS, muy mala idea. O en un comando ILMerge, idea excesivamente mala. Esos escenarios son mucho más problemáticos. Funciona bien siempre que el ensamblaje construido permanezca en la misma máquina. Pero no si viajan a otra máquina, una que tiene una versión de marco diferente instalada. Eso puede producir excepciones de tiempo de ejecución bastante desconcertantes, evidentes en this Q+A.

System.IO.dll es bastante exótico. Solo lo necesitará cuando ejecute System.CodeDom con una referencia a un ensamblado PCL. Su función principal es ocultar declaraciones, del tipo que no se debe utilizar en el perfil que seleccionó. El espacio de nombres System.IO necesita ocultarse porque estos tipos no se pueden usar cuando se dirige a WinRT. Pero la razón por la que no contiene ningún tipo, el [TypeForwardedTo] le dice al compilador que el tipo es compatible con una máquina de escritorio y para buscar la declaración en otro lugar, mscorlib.dll