.net - mscorlib.dll & System.dll

Question

Why did MS originally make the decision to maintain these two separate core libs? Maybe they had some scalability issue in mind, but nowadays I never see an application, of any type, that doesn't need both. Does anyone have any inside information on this? It's not really important, but been on my mind for years.

PS. I know what's in the two libs, I know the difference - I'm a big fan of Reflector :) Just wondering what practical use the separation of the two has.

Answer 1

I work on the CLR/BCL team and just answered your email. Here it is pasted below:

Jared's answer on Stack Overflow is right on. mscorlib.dll is tightly bound to the CLR for the reasons he mentions. Note that mscorlib.dll itself doesn't contain any native code (as Scott suggests), but there are many places where it needs to call directly into the CLR. As such, the CLR and mscorlib must be versioned together.

System.dll on the other hand is not tightly bound to the CLR (it doesn't require any calls into the runtime). We consider System.dll to be at a higher layer than mscorlib.dll. Having these assemblies in two separate layers allows for more flexibility, making it easier to version System.dll separately from the CLR/mscorlib.dll version (if we wanted to do so). We could, in theory, make changes and add functionality to System.dll without revving the CLR/mscorlib version. The separation also makes it easier to manage dependency rules between components in these different layers.

As Scott mentions, it does seem like there's a lot of "optional" stuff in mscorlib. This is mainly for historical reasons and because some things are just needed by other things. For example, there's no technical reason why System.IO.IsolatedStorage needs to be in mscorlib, but that's just where it happened to be added in 1.0, before we really thought about such versioning/layering concerns. Also, List is in mscorlib because other code in mscorlib has a need for a basic list collection.

Long term we'd like to reduce the amount of "optional" stuff in mscorlib as much as possible. Either by pushing stuff out of mscorlib or creating a new, more core, assembly that just contains the bare minimum necessary types (e.g. System.Object, System.Int32, etc.) to make managed code work. This will give us the flexibility to add new innovations to the "optional" stuff, and make it easier to create different .NET Framework SKUs (e.g. the .NET Client Profile, Silverlight, etc.), without having to rev the runtime.

I hope this helps!

Thanks, Justin