Msscorlib.dll & system.dll

Question

Why did MS initially decide to maintain these two separate core libraries? They may have had a scalability problem, but currently I never see any type of application that doesn't need both. Does anyone have any inside information about this? This is not very important, but it has been in my opinion for many years.

PS. I know that in two libs, I know the difference - I am a big fan of Reflector :) It's just interesting what practical use is the separation of the two.

Answer 1

Mscorlib contains both native and managed code.

Among other things, it contains an implementation of System.Object, which must always be present for everything to work.

It differs in that it is the only assembly that the CLR requires loading within each managed process.

Initially, a lot of “optional” material was added to “mscorlib” (things that are not technically required to run the application), because these were things that everyone would probably use. This includes things like HashTable and List.

This gave a powerful impetus. If everyone wants to use something, then it makes sense to insert it into the assembly, which everyone should download. Then you do not need to spend time collecting and linking a whole group of different assemblies.

The material in system.dll was mainly something that was not “worthy” for inclusion in mscorlib.

This trend, however, is beginning to change. CLR is making efforts to reduce the size of mscorlib. For example, a lot of material has been removed for Silverlight (to reduce download size).

I think they can do more of this kind of thing for V4 (and later), but I'm not sure about the details.

Answer 2

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

Jared's answer to Stack Overflow Right to. mscorlib.dll is closely related to the CLR for the reasons it mentions. Please note that mscorlib.dll itself does not contain any native code (as Scott suggests), but there are many places where you need to call the CLR directly. Therefore, the CLR and mscorlib must be versioned together.

System.dll, on the other hand, is not closely related to the CLR (it does not require any calls at run time). We consider System.dll as higher than mscorlib.dll. Having these assemblies in two separate layers allows flexibility, which facilitates the version of System.dll separately from the CLR / mscorlib.dll version (if we want to). Theoretically, we could make changes and add the functionality of System.dll without the CLR / mscorlib version. Separation also simplifies the management of dependency rules between components in these different layers.

As Scott mentions, it looks like there is a lot of “optional” stuff in mscorlib. This is mainly for historical reasons and things are simply necessary for other things. For example, there is no technical reason why System.IO.IsolatedStorage should be in mscorlib, but what exactly was added there in 1.0 before we really thought about such problems with version / bundle. Also, the List is in mscorlib because other code in mscorlib needs a main list.

In the long run, we would like to reduce the amount of “optional” material in mscorlib as much as possible. Either pushing material from mscorlib or creating a new, more core, assembly that simply contains the minimum minimum necessary types (for example, System.Object, System.Int32, etc.) to create workable code. This will give us the flexibility to add new innovations to the “optional” material and make it easier to create different .NET. Framework SKU (for example, .NET Client Profile, Silverlight, etc.), without the need to update the runtime.

Hope this helps!

Thanks Justin

Answer 3

Scott's answer extension.

Any version of the CLR is strongly tied to a specific version of mscorlib.dll. This is a special DLL in so many ways. CLR runtime requires certain types / methods and implements many methods defined in the actual code base. The complexity of managing these relationships is reduced by having an inextricable link between the CLR version and the mscorlib version.

Answer 4

Take a look at any project. Links node. You will not find mscorlib.dll here. This is special; any compiler needs it because it contains the types necessary for the language syntax to work. System.Array, System.Int32, System.String, System.Exception, etc.

You can write a program that is not dependent on System.dll (although it will be difficult), but you cannot write one that is not dependent on mscorlib.dll

Answer 5

The mentioned nation / controlled thing sounds believable, but I'm still not quite convinced. In any case, MS seems to consider mscorlib.dll as the base library needed for the system, while System.dll contains the basic functions for programmers, which also sounds good.

I just posted this question to the BCL team. If anyone can answer ... When (if?) I get a response, I will post it here. Thanks for the answers so far!

Answer 6

This is just an assumption, but mscorlib.dll also probably has some C code that is important for the CLR runtime, as well as a .NET assembly or some kind of mixed mode. System.dll is probably all managed.