Programming .NET Components, 2nd Edition

Application Domains

All .NET components and applications require a managed environment to run in. However, the underlying operating system knows nothing about managed code; it provides processes only. Processes are also unaware that .NET exists; they provide raw elements such as memory, handle tables, and so on. Managed code therefore can’t execute directly in the native operating system process—there is a need for a bridge between managed code and unmanaged code. The bridging link is a concept called an application domain, or app domain. You can think of the app domain as the .NET equivalent of a process, with one important difference: an app domain is built on top of the unmanaged process, and there is no requirement for one-to-one mapping between app domains and operating system processes. As a result, a single physical process can actually host multiple app domains (see Figure 10-1).

Figure 10-1. Processes, app domains, and assemblies

App Domains Versus Physical Processes

App domains are better perceived as logical processes, instead of real processes. The fact that a single physical process can host multiple app domains yields important benefits. The main reason why developers resorted to multiple processes in the past was to provide fault isolation. If all the components of an application and their clients are in the same process and a component has a fatal error that crashes ...