This print for content only-size & color not accurate 7" X 9-1/4" / casebound / malloy

■

P R O C E S S E S, A P P D O M A I N S, A N D   O B J E C T C O N T E X T S

571

8849CH17.qxd  10/9/07  4:29 PM  Page 571

---

• AppDomains are a key aspect of the OS-neutral nature of the .NET platform, given that this

logical division abstracts away the differences in how an underlying OS represents a loaded

executable.

• AppDomains are far less expensive in terms of processing power and memory than a full-

blown process. Thus, the CLR is able to load and unload application domains much quicker

than a formal process.

• AppDomains provide a deeper level of isolation for hosting a loaded application. If one

AppDomain within a process fails, the remaining AppDomains remain functional.

As suggested in the previous hit list, a single process can host any number of AppDomains,

each of which is fully and completely isolated from other AppDomains within this process (or any

other process). Given this fact, be very aware that an application running in one AppDomain is

unable to obtain data of any kind (global variables or static fields) within another AppDomain

unless they make use of a distributed programming protocol (such as Windows Communication

Foundation).

While a single process 

may host multiple AppDomains, this is not typically the case. At the very

least, an OS process will host what is termed the 

default application domain. This specific applica-

tion domain is automatically created by the CLR at the time the process launches. After this point,

the CLR creates additional application domains on an as-needed basis.

If the need should arise (which it most likely 

will not for the majority of your .NET endeavors),

you are also able to programmatically create application domains at runtime within a given process

using static methods of the System.AppDomain class. This class is also useful for low-level control of

application domains. Key members of this class are shown in Table 17-4.