The .NET Framework ships with runtime hosts that support a few common scenarios, including a host used by ASP.NET and a host used by Microsoft Internet Explorer. The .NET Framework SDK also provides an unmanaged API that you can use to write custom runtime hosts. For example, you might write a custom runtime host for an application server product that can run code from multiple users simultaneously. The custom runtime host can enable customers of the application server to write managed code that can provide benefits such as increased scalability, a common type system, multilanguage support, automatic memory management, and so on. If specialized tools, such as debuggers, act as runtime hosts, they can access information such as the list of application domains running in the process.
Most runtime hosts consist of both unmanaged and managed code. The unmanaged hosting code loads the runtime into the process when the process starts. Once the runtime has been loaded into the process, control can be transferred to the managed portion of the hosting code, to improve performance. Implementing the portion of the host that interacts with user code in managed code results in better performance because calls from the hosting code to the user code are made in the managed environment. If you wrote the entire host in unmanaged code, you would have to transition from unmanaged code to managed code each time the hosting code and the user code interact.
Unmanaged hosting code is used to configure the common language runtime, load it in the process, and transition the program into managed code. The managed portion of the hosting code creates the application domains in which user code will run and dispatches user requests to the created application domains.