Relationship between .NET ClassLoader and Assembly

Question

I am wondering about the relationship between .NET ClassLoader and Assembly

I use the "!dumpdomain xxxx" command and got the following output:

Domain 1: 00522108 
LowFrequencyHeap: 0052212c
HighFrequencyHeap: 00522178
StubHeap: 005221c4
Stage: OPEN
SecurityDescriptor: 00523430
Name: BoxUnbox.exe
**Assembly**: 0056eb88 [C:\Windows\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll]
**ClassLoader**: 0056ec08
SecurityDescriptor: 0056c078
Module Name 
56d71000 C:\Windows\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll

**Assembly**: 005794f0 []
**ClassLoader**: 00579570
SecurityDescriptor: 0057a018
Module Name 
00152c5c

I noticed that the "ClassLoader" and "Assembly" appear in pair. It seems each Assembly is accompanied with its own "ClassLoader".

Why design like this? Is this a litte noisy? Why not just assign one "ClassLoader" to an AppDomain and use it to load all the Assembly needed by the AppDomain? Isnt't this design more elegant?

Many thanks.

Answer 1

There's an instance of the ClassLoader class associated with each assembly. It loads types from the assembly. It has a bunch of debug fields that are only present when the CLR is built in Debug mode. The pointer to the ClassLoader instance is no doubt listed to help a Microsoft tester find that debug data back. It isn't going to be very interesting the retail build.

You can find the source code for this in the SSCLI20 distribution. The class loader is declared in clr\\src\\vm\\clsload.hpp. In case it matters: it has nothing to do with the Java notion of a class loader.