Customizing the Microsoft .NET Framework Common Language Runtime

The CorBindToRuntimeEx API gives you explicit control over when the CLR is loaded and enables you to configure the basic settings that determine how the CLR behaves in your process. By using CorBindToRuntimeEx you can specify which version of the CLR gets loaded, whether the CLR is optimized for a server application or a workstation application, and how code is shared across the application domains in the process. Of these settings, determining the most appropriate version to load is the most complex because you must understand the implications of having more than one version of the .NET Framework installed on a single machine. In addition to understanding the basic side-by-side architecture of the CLR, you also must be aware of more subtle issues such as the impact of CLR servicing releases on the version you choose. Although the CLR has rich support to customize startup, the support to control CLR shutdown is less sophisticated. There is no way to remove the CLR from a process completely after it has been loaded, but you can disable it. Disabling the CLR prevents you from running managed code in the future and removes some of the CLR files and data structures from the process, but the shutdown isn't completely clean. In addition, even if you disable the CLR in this fashion, you cannot restart it again. You must start an entire new process to reinitialize the CLR.