An application domain is the runtime unit of isolation in which a .NET program runs. It provides a managed memory boundary, a container for loaded assemblies, and application configuration settings, as well as delineating a communication boundary for distributed applications.
Each .NET process usually hosts just one application domain: the default domain, created automatically by the CLR when the process starts. It’s also possible—and sometimes useful—to create additional application domains within the same process. This provides isolation while avoiding the overhead and communication complications that arise with having separate processes. It’s useful in scenarios such as load testing and application patching, and in implementing robust error-recovery mechanisms.
This chapter is irrelevant to Windows Store and CoreCLR apps, which have access to only a single application domain.
Figure 24-1 illustrates the application domain architectures for single-domain, multidomain, and typical distributed client/server applications. In most cases, the processes housing the application domains are created implicitly by the operating system—when the user double-clicks your .NET executable file or starts a Windows service. However, an application domain can also be hosted in other processes such as IIS or in SQL Server through CLR integration.
In the case of a simple executable, the process ends when the default application ...