The CLR (written in native code) is only loaded once per process and the code segments are shared amongst (.NET) processes.

"The CLR (written in native code) is only loaded once per process and the code segments are shared amongst (.NET) processes. "

It sounds as though you are saying for each assembly loaded that does not reference some group of assemblies but works with referenced assemblies in the same process, the CLR is loaded once.

For example:

[One CLR instance]

 - A.exe loads - this loads a CLR instance. A.exe references B.dll

 - B.dll loads into the A.exe app domain.

[Two CLR instances]

- A.exe loads same as above

- B.exe loads and only references X.dll. Another CLR instance loads into the B.exe process. X.dll loads into the B app domain.

Note that it's not quite correct to talk about CLR "instances", the CLR is just a bunch of native code DLL's, and these DLL's are mapped into the process address space. That means that and the "A" process and the "B" process will each map the CLR DLL's. Note that I say 'mapped', that means that while each process will get it's private copy of the non sharable pages in the DLL (some of the data pages) loaded in the process address space, each one will share the sharable pages (the code pages) across the processes. Now, this is exactly what the CLR is unable to do - share JIT compiled code pages across processes and AD's, but NGEN'd code can be shared which is great for Terminal Server scenario's and other.