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

Mscorlib does contains both native and managed code.

Amongst other things it contains the System.Object implementation, which must always be present in order for everything to work.

It has the distinction of being the only assembly that the CLR requires to be loaded inside every managed process.

Originally, a lot of ‘optional’ stuff (things that technically aren’t required to run an app) was put into mscorlib because they were things that were highly likely to be used by everybody. This includes things like HashTable and List.

This gave a perf boost. If everybody is going to want to use something, then it makes sense to put it inside the assembly that everybody has to load. Then you don’t have to waste time going and binding a whole bunch of different assemblies.

The stuff in system.dll was basically everything that wasn’t ‘worthy’ of being included in mscorlib.

This trend, however, is starting to be reversed. The CLR is making efforts to reduce the size of mscorlib. A lot of stuff was removed for Silverlight for example (to reduce download size).

I think they might be doing more of this kind of stuff for V4 (and later versions) but I’m not sure about the details.