C H A P T E R 17
Processes, AppDomains, and
Object Contexts
In Chapters 14 and 15, you examined the steps taken by the CLR to resolve the location of a referenced
external assembly, as well as the role of .NET metadata. In this chapter, you’ll drill deeper into the details
of how an assembly is hosted by the CLR and come to understand the relationship between processes,
application domains, and object contexts.
In a nutshell, application domains (or simply AppDomains) are logical subdivisions within a given
process that host a set of related .NET assemblies. As you will see, an AppDomain is further subdivided
into contextual boundaries, which are used to group together like-minded .NET objects. Using the
notion of context, the CLR is able to ensure that objects with special runtime requirements are handled
appropriately.
While it is true that many of your day-to-day programming tasks might not involve directly working
with processes, AppDomains, or object contexts, understanding these topics is very important when
working with numerous .NET APIs, including Windows Communication Foundation (WCF),
multithreading and parallel processing, and object serialization.
The Role of a Windows Process
The concept of a “process” has existed within Windows-based operating systems well before the release
of the .NET platform. In simple terms, a process is a running program. However, formally speaking, a
process is an operating system–level concept used to describe a set of resources (such as external code
libraries and the primary thread) and the necessary memory allocations used by a running application.
For each *.exe loaded into memory, the OS creates a separate and isolated process for use during its
lifetime.
Using this approach to application isolation, the result is a much more robust and stable runtime
environment, given that the failure of one process does not affect t H