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