Section I: CLR Homestay

This series of articles from the CLR VIA C #

The. NET framework runs at the top of the Microsoft Windows platform. This means that. NET must be built with technologies that Windows can understand. First, all the managed modules and assembly files must use the Windows PE file format, and either a Windows.exe file or a DLL file.

When developing the CLR, Microsoft actually implements it as a COM server that is contained in a single DLL. That is, Microsoft defines a flag's COM interface for the CLR and assigns a GUID (Global universal Identifier) to the interface and to the COM server. When you install the. NET Framework, the COM server representing the CLR is registered in the window registry just like other COM servers. For more information about this, refer to the C + + header file MetaHost.h published with the. NET Framework SDK. The GUID and unmanaged ICLRMetaHost interfaces are defined in the header file.

Any window application can host the CLR. However, instead of creating an instance of the CLR COM server by calling CoCreateInstance, your unmanaged host should call the CLRCreateInstance function declared in the MetaHost.h file. The CLRCreateInstance function is implemented in the MSCorEE.dll file, which is typically in the C:\Windows\System32 directory. This DLL is called "Shim (Shim)" and its work decides to create that version of the CLR; note that the shim itself does not contain a CLR COM server.

A single machine can install multiple versions of the CLR, but only one version of the MSCorEE.dll file (X86 schema only). The version of MSCorEE.dll installed on the machine is the one released with the latest CLR installed on the machine. Therefore, the version of MSCorEE.dll knows how to find the CLR that may be installed on the previous version of the machine.

The name of the file that contains the actual CLR code is different in different versions of the CLR. For 1.0,1.1 and version 2.0, CLR code is actually a file named MSCorWks.dll, and for version 4.0, the CLR code is in a file named Clr.dll. Because multiple versions of the CLR may be installed on a machine, these files are installed in different directories.

Version 1.0 C:\Windows\Microsoft.NET\Framework\v1.0.3705

Version 2.1 C:\Windows\Microsoft.NET\Framework\v1.1.4322

Version 2.0 C:\Windows\Microsoft.NET\Framework\v2.0.50727

Version 4.0 C:\Windows\Microsoft.NET\Framework\v4.0.30319

The CLRCreateInstance function can return a ICLRMetaHost interface. The host application can call the GetRuntime function of this interface to specify the version of the CLR that is primarily created by the host. The shim then loads the required version of the CLR into the host's process.

By default, when a managed executable file is started, the Shim examines the executable file, extracting the version information of the CLR that was used when the application was built and tested. However, the application can set both Requiredruntime and supportedruntime in its XML file to override the default behavior.

The GetRuntime function returns a pointer to an unmanaged interface ICLRRuntimeInfo. With this pointer, you can use the GetInterface method to get the ICLRRuntimeHost interface. The host application can invoke the method of this interface to do the following things:

1. Set up a host manager. Tells the CLR that the host wants to participate in decisions that involve the following: memory allocation, thread scheduling/synchronization, and assembly loading. The host can also declare that it wants to be notified about garbage collection start and stop and specific operation timeouts.
2. Gets the CLR manager. Tells the CLR to block the use of certain classes/members. In addition, the host can tell which code can be debugged, which code is not, and which methods the host should invoke when a particular time occurs.
3. Initializes and starts the CLR.
4. Loads the assembly and executes the code within it.
5. Stop the CLR and prevent any more managed code from running in the Windows process.

Note: Of course, the window process can completely not load the CLR. You need to load it only if you need to execute managed code in the process. Prior to CLR 4.0, a Windows process allowed only one instance of the CLR to be loaded. In other words, in a process, either contains no CLR, or contains either CLR v1.0,clr V1.1 or one of CLR 2.0. Only allow each process to contain one version of the CLR with a huge limit. For example, Microsift Office Outlook cannot load two add-ins that build and test items for different versions of the. NET Framework.

However, with the release of the. NET Framework 4.0, Microsoft supports the simultaneous loading of CLR V2.0 and V4.0 in a single Windows process, allowing for the. NET Framework 2.0 and 4.0 write different components to run at the same time without causing any compatibility problems.

After a CLR is loaded into a Windows process, it can never be unloaded, and when the AddRef and release methods on the ICLRRuntimeHost interface are called, the only way the CLR unloads from the process is to terminate the process. This causes all resources used by the window cleanup process, including the CLR.

There are many reasons why a hosted CLR can be useful. Hosting enables any application to provide CLR functionality and programmability, and at least a subset of it can be written in managed code. If a developer wants to extend an application, the hosted CLR can provide multiple benefits, as summarized below.

1. Can be written in any programming language.
2. The code executes after JIT compilation, so it's fast
3. The code uses garbage collection to avoid memory leaks and corruption.
4. The code runs in a secure sandbox.
5. The host does not have to provide a rich development environment. The host leverages existing technologies, including languages, compilers, editors, debuggers, profilers, and more.

Section I: CLR Homestay