Application Domains

Application domains have previously been described as subprocesses within a process. Processes are the unit of fault tolerance within an operating system. If one process behaves erroneously, such as by trying to access the memory of another process's address space, then the operating system will terminate the erroneous process but leave all other processes unaffected. However, processes are often expensive in terms of resource usage, because the operating system must continually monitor processes. By comparison, a number of application domains can exist with a single process, yet require no extra overhead from the operating system. Instead, the execution system manages the application domains. Compared with using multiple processes, application domains offer even more advantages. With application domains, threads that switch from one application domain to another do not incur the same costs as if they switched from one process to another. It is also possible to remove an application domain from a process without adversely affecting the process or the other application domains within that same process, just as you can remove an errant process from memory without affecting other processes.

An assembly is always loaded into an application domain ”normally, the application domain that requested it. Assemblies can be domain-neutral , meaning that the code within an assembly is shared between all application domains. For example, mscorlib is always loaded as a domain-neutral assembly. This approach resembles the shared use of a DLL between processes. Sometimes assemblies must be loaded as domain-specific ”if, for example, they will receive different permissions depending on their use. References to data from assemblies in other application domains naturally cross application domain boundaries and are subject to constraints. For example, an object cannot directly access data in an object in another application domain; instead, either a copy of the object will be placed in the client's application domain or a proxy object will provide the necessary access.

Figure 4.1 depicts a simplified view of an executing CLR application. A process may contain one or more application domains; in the figure, it has two. Each application domain may contain one or more assemblies. Each assembly may contain one or more modules.

Figure 4.1. An executing CLR application

Effectively, threads remain independent of application domains. Thus, threads can cross from one application domain to another, and an application domain can have more than one thread. Developers rarely interact directly with application domains, although such interaction is possible if the need for it arises. The Base Framework includes an AppDomain class that developers can use to manipulate application domains. Application domains are covered in more detail in Chapter 5.

If cordbg was started on the IL-generation program given in Listing 4.1, then typing the ap command at the cordbg prompt would display the application domains. The following output has been edited for brevity:

 (cordbg) ap  1) * AppDomainName = <SampleIL.exe>         DebugStatus: <Debugger Attached >         ID: 1         Assembly Name :             C:\Project7\Demos\SampleIL\SampleIL.exe             Module Name :                 C:\Project7\Demos\SampleIL\SampleIL.exe         Assembly Name :             c:\...\framework\v1.0.3705\mscorlib.dll             Module Name :                 c:\...\framework\v1.0.3705\mscorlib.dll 

This output shows one application domain, SampleIL.exe, with two assemblies loaded ”namely, SampleIL.exe and mscorlib.dll . Each assembly has one module ” SampleIL.exe and mscorlib.dll , respectively.