-----------------------------------------------------------

New Message on BDOTNET

-----------------------------------------------------------
From: SitaramanM
Message 6 in Discussion

Hi   Instance of a CLR is bound to a process.  So if i have two apps in two proceses i 
will have two separate CLR instances.  So   Let me explain Mani's statement "CLR is 
actually implemented as a COM Server" . To be precise, The CLR is ultimately a family 
of Win32/COM DLLs that one can load into any Win32 process(Note this point). So the 
CLR is actually a family of dlls.  The primary facade to the CLR is MSCOREE.DLL.  this 
is what is called as the Shim dll whose responsibility is to load the actual CLR 
implementation, which is MSCORWKS.dll(UniProcessor build of the CLR) (or) 
MSCORSVS.dll(multi-Procerssor build of the CLR).     Microsoft defined a standard COM 
interface for the CLR and assigned GUIDs to this interface and the COM server. When 
you install the .NET Framework, the COM server representing the CLR is registered in 
the Windows registry just like any other COM server. If you want more information 
about this topic, refer to the MSCorEE.h C++ header file that ships with the .NET 
Framework SDK. This header file defines the GUIDs and the unmanaged ICorRuntimeHost 
interface definition.   Any Windows application can host the CLR by caling the 
CorBindToRuntimeEx function (prototyped in MSCorEE.h). The CorBindToRuntimeEx function 
is implemented in the MSCorEE.dll, which is usually found in the C:\Windows\System32 
directory. This DLL is called the shim, and its job is to determine which version of 
the CLR to create as the shim DLL doesn�t contain the CLR COM server itself. When 
CorBindToRuntimeEx is called, its parameters allow the host to specify which version 
of the CLR it would like to create. The version information indicates workstation 
vs.server as well as a version number. CorBindToRuntimeEx uses the specified version 
information and gathers some additional information of its own (such as how many CPUs 
are installed in the machine and which versions of the CLR are installed) to decide 
which version of the CLR to load�the shim might not load the version that the host 
requested.    Also note that onece a version of a CLR is loaded into memory another 
instance cannot be made withing the same process. In version 1 of the .NET Framework, 
no more than one CLR COM server object can exist in a Windows process, and this CLR 
COM server object can�t be destroyed until the hosting process terminates(Even if the 
CLR COM Server is completely torn down); that is, CorBindToRuntimeEx creates an 
instance of a CLR COM server and returns a pointer to an ICorRuntimeHost interface. 
Calling the AddRef and Release methods on this interface has no effect. In addition, a 
single host process can create only one instance of a CLR COM server. If a single host 
process calls CorBindToRuntimeEx multiple times, the same ICorRuntimeHost pointer is 
returned every time.   That said let me try to give a proof of concept for the fact 
that CLR instance is per-process Note that the CLR has many tasks that it performs 
when it is initialized within a process. Part of this initialization is to create the 
managed heap that all reference objects get allocated in and garbage collected from. 
In addition, the CLR creates a thread pool usable by any of the managed types whose 
assemblies are loaded into the process. While initializing, the CLR also creates an 
AppDomain(Default).which is destroyed only when the Windows process terminates.   So 
if there is one instance of CLR then it also means that there is only one copy of the 
managed heap and one thread pool.  So if i do a GC on a managed heap then the GC 
should affect all the application(coz one instance of clr=one instance of managed 
heap).  This never happens and can be checked.       hth   regards,   sr   p.s. if you 
look at the registry, you will find that only the MSCOREE.dll, the shim has a 
corresponding HKCR registry entry and not the other CLR components.  In fact only the 
SHIM exports the DLLRegisterServer and DLLUnRegisterServer which is needed to register 
a com component. The MSCORWKS(the CLR implemntation for Uniprocessor build) for 
example exports a DLLRegisterServerInternal function only.  So from a COM point of 
view, it is only the SHIM which makes any difference!!!

-----------------------------------------------------------

To stop getting this e-mail, or change how often it arrives, go to your E-mail 
Settings.
http://groups.msn.com/BDotNet/_emailsettings.msnw

Need help? If you've forgotten your password, please go to Passport Member Services.
http://groups.msn.com/_passportredir.msnw?ppmprop=help

For other questions or feedback, go to our Contact Us page.
http://groups.msn.com/contact

If you do not want to receive future e-mail from this MSN group, or if you received 
this message by mistake, please click the "Remove" link below. On the pre-addressed 
e-mail message that opens, simply click "Send". Your e-mail address will be deleted 
from this group's mailing list.
mailto:[EMAIL PROTECTED]

Reply via email to