mscorlib.dll & System.dll

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.

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

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.

Expanding on Scott's answer.

Any given version of the CLR is highly tied to a particular version of mscorlib.dll. It is a special DLL in very many ways. The CLR runtime requires certain types/methods be available and implements many methods defined in the actual code base. The complexity of managing this relationship is reduced by having an unbreakable link between a CLR version, and version of mscorlib.

Take a good look at any project's References node. You'll never find mscorlib.dll listed there. It is special, any compiler needs it because it contains types that are required to make the language syntax work. System.Array, System.Int32, System.String, System.Exception, etc.

You can write a program that doesn't have a dependency on System.dll (although it would be hard) but you can't write one that doesn't depend on mscorlib.dll

The mentioned native/managed thing sounds plausible, but I'm still not entirely convinced. In any case, MS seems to view mscorlib.dll as the core lib needed for the system, while System.dll contains the core functionality for programmers - which also sounds good.

I've just emailed this same question to the BCL team. If anyone can answer... When (if?) I receive an answer, I'll post it here. Thanks for the answers so far!

This is just a guess, but mscorlib.dll probably also has some C code that's important to the CLR runtime as well as being a .NET assembly, or some mixed-mode code. System.dll is probably all managed.