CHAPTER 17 PROCESSES, APPDOMAINS, AND OBJECT CONTEXTS
***** Fun with Object Context *****
ObjectContextApp.SportsCar object in context 0
-> Ctx Prop: LeaseLifeTimeServiceProperty
ObjectContextApp.SportsCar object in context 0
-> Ctx Prop: LeaseLifeTimeServiceProperty
ObjectContextApp.SportsCarTS object in context 1
-> Ctx Prop: LeaseLifeTimeServiceProperty
-> Ctx Prop: Synchronization
Given that the SportsCar class has not been qualified with a context attribute, the CLR has allocated
sport and sport2 into context 0 (i.e., the default context). However, the SportsCarTS object is loaded into
a unique contextual boundary (which has been assigned a context ID of 1), given the fact that this
context-bound type was adorned with the [Synchronization] attribute.
Source Code The ObjectContextApp project is included under the Chapter 17 subdirectory.
Summarizing Processes, AppDomains, and Context
At this point, you hopefully have a much better idea about how a .NET assembly is hosted by the CLR. To
summarize the key points:
•
A .NET process hosts one to many application domains. Each AppDomain is able
to host any number of related .NET assemblies. AppDomains may be
independently loaded and unloaded by the CLR (or programmatically via the
System.AppDomain type).
•
A given AppDomain consists of one to many contexts. Using a context, the CLR is
able to place a “special needs” object into a logical container, to ensure that its
runtime requirements are honored.
If the previous pages have seemed to be a bit too low level for your liking, fear not. For the most part,
the CLR automatically deals with the details of processes, application domains, and contexts on your
behalf. The good news, however, is that this information provides a solid foundation for understanding
multithreaded programming under the .NET platform.
Summary
The point of this chapter was to examine exactly how a .NET-executable image is hosted by the .NET
platform. As you have seen, the long-standing notion of a Windows process has been altered under the
hood to accommodate the needs of the CLR. A single process (which can be programmatically
manipulated via the System.Diagnostics.Process type) is now composed of one or more application
domains, which represent isolated and independent boundaries within a process.
649