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)?

Oconnor

I can only speculate but maybe platform portability for future releases? In Rx Bart de Smet has shifted around stuff between assemblies to factor out platform specifics as much as possible. – Flunkey

Doesn't appear to be present in vanilla v4. – Adebayo

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

Sharp

I'm conflicted about accepting this answer. It's not a reference assembly - it's from C:\Windows\Microsoft.Net\framework\v4.0.30319 alongside other core, framework (non-reference) assemblies and is identical to the one stored in the GAC. So paragraphs 1 and 5 are not correct. Paragraph 4 also misses the target - it can hardly be for legacy reasons when it was introduced for v4.5. But paragraph 3 does seem to be about right. – Oconnor