Runtime Initialization from a COM Application
Before a COM application can activate a managed type, the common language runtime must be loaded into memory. Although COM interop does not actually load the runtime (runtime startup code does), a COM application can target a specific version of the runtime.
The following factors determine the runtime version:
A COM application can specify the runtime version in an application configuration file. For additional information, see Configuring a COM Application for Side-by-Side Execution.
The runtime can already be loaded into memory by an extensible host, such as Microsoft Internet Explorer or Microsoft Office. The plug-in COM application uses the runtime that is loaded for the host to run managed components.
When strict control is needed, a COM application can preload a specific version of the runtime programmatically by invoking the ICLRMetaHostPolicy::GetRequestedRuntime method (exported from mscoree.dll). Alternatively, the application can target a different version of the runtime, based on an activated COM class, by invoking the GetRequestedRuntimeVersionForCLSID function (also exported from mscoree.dll) and passing the return value to the CorBindToRuntimeHost function.
In the absence of these factors, the startup code loads the runtime according to the default loading behavior described in Configuring a COM Application for Side-by-Side Execution.
If multiple versions of an assembly containing the type to be activated are present in the Windows registry, the runtime loads the latest version by default.
If the COM application has an application configuration file, binding can be redirected to a type in a specific version of an assembly. For additional information, see Configuring a COM Application for Side-by-Side Execution.
Components installed with the .NET Framework version 1.0 do not have version-dependent registry keys. For these components, there is only one version of a type on the computer available for use by COM.