The CLR and Process Lifetime
The CLR and Process LifetimeOnce loaded into a process, the CLR can never be completely removed. That is, there is no way to guarantee that all files and data structures associated with the CLR are cleaned up and all the memory they required is returned. You can, however, disable the CLR. Specifically, when you disable the CLR, it no longer is able to run managed code in the process. The process itself is not damaged in the sense that unmanaged code continues to run just fine, but further attempts to run managed code are not honored. You disable the CLR by using the Stop method on ICLRRuntimeHost . Calls to Stop must be paired with calls to ICLRRuntimeHost::Start , which is discussed earlier in the chapter. That is, you must call Stop once for each call you made to Start for the CLR to be disabled. It's also important to note that once the CLR has been disabled using Stop , it can never be restarted in the same process again. 
|
Summary
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
|
Chapter 4. Using the Default CLR HostThe CLR ships with a default host that you can use to run managed code in any process without having to write your own CLR host. That is, you don't have to include code in your application to call CorBindToRuntimeEx , interact with the CLR through the ICLRRuntimeHost interface, and so on. The goal of this chapter is to provide enough details about the default CLR host to help you determine whether it meets the requirements of your scenario. If the capabilities provided by the default host meet your needs and if you don't require the additional functionality provided by the CLR hosting APIs, using the default host can save you time and effort.
The default host is invoked in one of two ways. First, the default host is used to run managed executables launched from the command line or from the shell. The second use of the default host is to run managed types that have been introduced to a process through the CLR's COM interoperability layer. This second method of invoking the default host can fit with a wide range of scenarios. Any application that exposes an extensibility model based on COM (or creates COM
Using the default host doesn't provide all of the flexibility you get by writing a host yourself, but you can configure many of the CLR startup options through application configuration files (see Chapter 3 for details on what the CLR startup options are). Understanding how the default host gets activated, what its default values are for the CLR startup options, and the degree to which these defaults can be customized helps you determine whether using the default host is appropriate in your application. |