What is the point of System.IO.dll?

Question

So far as I'm aware, most of the below types are now, and have always been, defined in mscorlib and/or System.dll.

However, in looking in the v4 framework directories (I have 4.5 installed, not sure if it also exists in Vanilla v4), I find an assembly called System.IO.dll.

Examining it in reflector, I can't see any actual code. All I can find are the following entries:

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

All pointing back to mscorlib (I think, haven't checked all of them). I've had a look around, and I can't see any framework version (e.g. silverlight, compact, etc) where these types aren't in mscorlib. So, does anyone know why this assembly exists (and why now)?

Answer 1

You found a reference assembly. That may sound odd, since you definitely don't use such a reference assembly in a .NET project that targets .NET >= 4.0. You normally get them from the C:\Program Files (x86)\Reference Assemblies directory on your dev machine. But that is not the only scenario in which a compiler is used. You also use a compiler when you use System.CodeDom in your program or depend on XML serialization.

Specific about System.CodeDom and XML serialization is that the compiler runs on your user's machine. And that you cannot target a specific .NET Framework version. Your user's machine does not have the targeting packs that your machine has. So its gets whichever version happens to be installed on the machine. The files in C:\Windows\Microsoft.NET\Framework\v4.0.30319 contains the reference assemblies that match that installed version. If the machine gets updated with another .NET 4.x release then those reference assemblies get updated as well.

Not the only possible scenario, likely that you'll also use them when you build from the command line. Or on a build server and decided to not pay for a VS license, very bad idea. Or in an ILMerge command, excessively bad idea. Those scenarios are a lot more troublesome. It works okay as long as the built assembly stays on the same machine. But not if they travel to another one machine, one that has a different framework version installed. That can produce pretty mystifying runtime exceptions, evident in this Q+A.

System.IO.dll is fairly exotic. You are only going to need it when you run System.CodeDom with a reference to a PCL assembly. Its primary role is to hide declarations, the kind that should not be used in the profile you picked. The System.IO namespace needs hiding because these types cannot be used when you target WinRT. But otherwise the reason that it doesn't contain any types, the [TypeForwardedTo] tells the compiler that the type is supported on a desktop machine and to look for the declaration elsewhere, mscorlib.dll