Customizing the Microsoft .NET Framework Common Language Runtime

The 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 components as part of the application itself) can use the default host to extend the application with the capabilities of managed code.

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.