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

■

Source Code

The AppDomainManipulator project is included under the Chapter 17 subdirectory.

Understanding Object Context Boundaries

As you have just seen, AppDomains are logical partitions within a process used to host .NET assem-

blies. On a related note, a given application domain may be further subdivided into numerous

context boundaries. In a nutshell, a .NET context provides a way for a single AppDomain to estab-

lish a “specific home” for a given object.

Using context, the CLR is able to ensure that objects that have special runtime requirements

are handled in an appropriate and consistent manner by intercepting method invocations into and

out of a given context. This layer of interception allows the CLR to adjust the current method invo-

cation to conform to the contextual settings of a given object. For example, if you define a C# class

type that requires automatic thread safety (using the [Synchronization] attribute), the CLR will

create a “synchronized context” during allocation.

Just as a process defines a default AppDomain, every application domain has a default context.

This default context (sometimes referred to as context 0, given that it is always the first context cre-

ated within an application domain) is used to group together .NET objects that have no specific or

unique contextual needs. As you may expect, a vast majority of .NET objects are loaded into context

0. If the CLR determines a newly created object has special needs, a new context boundary is cre-

ated within the hosting application domain. Figure 17-9 illustrates the process/AppDomain/

context relationship.

C H A P T E R   1 7