Regarding CLR Execution in .NET

[Shyam K Pananghat]

How many copies of the Common Language Runtime (CLR) can be executing on a machine at one time? I think there is only one image of the CLR running on a machine. It will try to load mscoree.dll into memmory only only if it is not there. it is not in a per application basis. am i right ??? :doh:

Shyam my blog dotnetscoups.blogspot.com . swthoughts.blogspot.com .

[Brady Kelly]

The CLR is loaded once per process, normally, as the Windows Process is the primary runtime host. However, it may be loaded fewer or more times in someone's custom build runtime host.

[Mike Dimmick]

An unlimited number, or one, depending on what you're talking about. There can be multiple versions of the .NET Framework CLR installed on a computer. There is however only one copy of mscoree.dll (per processor architecture), which is installed in the Windows System32 folder (on a 64-bit system, the 32-bit x86 version is in SysWOW64). This is really a stub responsible for loading the correct version of the real runtime (either mscorwks.dll or, for server GC on .NET 1.x, mscorsvr.dll). Each process can only have one version of the CLR loaded (right now, this is 1.0.3705, 1.1.4322, or 2.0.50727). The first version requested is the only one ever loaded in that process. Unless otherwise guided by an application config file, .NET DLLs loaded via COM Interop will cause the latest version of the CLR installed on the system to be loaded into that process. 64-bit processes can only load v2.0 of the CLR because .NET 1.x doesn't support 64-bit. Now we get into how Windows loads code and (initialised) data from program binaries (EXEs and DLLs). It actually loads them as shared (memory-mapped files) - the code and data are initially only in physical memory once. It also loads them on-demand - only when actually referenced, so loading a 5MB DLL doesn't immediately consume 5MB of physical memory. Writeable data pages are marked copy-on-write - they start out sharing the same data, but as soon as the process tries to write to the page, the OS makes a copy of it. Read-only and unchanged copy-on-write pages can be re-read from the original file, so when trying to free up physical memory, Windows can simply discard the page, rather than having to write it out to the page file. The page is said to be backed by the original file. Pages that have been written to, and dynamically-allocated pages, are backed by the page file. DLLs (and EXEs) have a base address. This is the virtual memory address, in the process's address space, that it would like to load at. Being the first thing to be loaded, the EXE always loads at its base address, but DLLs might have to be moved - relocated - elsewhere if there's something else already at that address (whether another DLL or some other allocation). Some native processor instructions only work with absolute addresses, which are written into the program code and data. When relocating a DLL, the OS has to change these addresses, so it copies the original page to a new page (backed by the page file) and modifies that. So ideally, t

[Luc Pattyn]

very interesting summary. I would like to be able to vote 6 or more. Even though, just maybe, the OP expected a more concise yes or no. Regards

Luc Pattyn

---

try { [Search CP Articles] [Search CP Forums] [Forum Guidelines] [My Articles] } catch { [Google] }

---

[Shyam K Pananghat]

Thanks Mike, Thanks a lot for that elaborated reply which helped me to clear my doubt. and i've voted 5 :)

Shyam my blog dotnetscoups.blogspot.com . swthoughts.blogspot.com .