Programming .NET Components, 2nd Edition

The .NET Context

Every new app domain starts with a single context, called the default context . The default context provides no component services at all. The main reason why it exists is to help maintain a consistent programming model. The first object created in the new app domain is placed in the default context, even if it isn’t a context-bound object. This maintains the design principle that all objects execute in a context, even if they don’t care about component services. An app domain can contain multiple contexts, and .NET creates new contexts as needed. There is no limit to the number of contexts an app domain can contain. A given context belongs to exactly one app domain and can host multiple context-bound objects (see Figure 11-1). Every context has a unique ID (an integer) called the context ID . The context ID is guaranteed to be unique in the scope of an app domain. Every .NET context has a context object associated with it. The context object is an instance of the class Context, defined in the System.Runtime.Remoting.Contexts namespace. You typically don’t need to interact with the context object. However, for diagnostics and tracing purposes, it’s sometimes useful to retrieve the context ID, using the ContextID read-only property of the context object:

    public class Context
    {
       public virtual int ContextID{get;}
       //Other members
    }

Every object can access the context object of the context it’s executing by using the CurrentContext static read-only property of the