|
The COM interfaces in the hosting API that the host and the CLR use to communicate with each other are grouped into what are called hosting managers. A hosting manager is nothing more than a convenient way to categorize a set of interfaces that work together to provide a logical grouping of functionality. For example, a host can use the hosting interfaces to provide a set of allocation primitives through which the CLR will direct requests to allocate memory. This manager is referred to as the memory manager and consists of the interfaces IHostMemoryManager and IHostMalloc. As another example, consider the manager that lets a host control various aspects of how assemblies are loaded in a process. Four interfaces are involved in providing this customization: IHostAssemblyManager, IHostAssemblyStore, ICLRAssemblyIdentityManager, and ICLRAssemblyReferenceList. These interfaces are grouped into what is called the assembly loading manager. Both of the managers in the preceding examples consist of multiple interfaces, as many managers are. In these cases, one of the interfaces is designated the primary interface. The main role of the primary interface (apart from implementing some of the functionality of the manager) is to participate in the discovery process, or the steps that are taken to identify which managers the host and the CLR implement. (More on this in the section entitled "Hosting Manager Discovery" later in this chapter.) A few important points about the hosting managers are worth highlighting. First, some managers are implemented by the CLR, some are implemented by the host, and some are split, in that both the host and the CLR implement portions of the manager that complement each other. The hosting interfaces follow a naming convention that makes it easy to tell whether a particular interface is implemented by the CLR or by the host. All interfaces that are implemented by the CLR start with ICLR, whereas those implemented by the host start with IHost. Second, the factoring of the API into a set of managers gives the host the flexibility to customize some, but not all, aspects of the CLR. Every manager is optional; that is, the host implements only those managers that support the customizations they require. However, if you decide to implement a particular manager, you must implement all of it. You cannot implement just those methods you choose and delegate the rest to the CLR defaults, for example. The fact that hosts get to pick only those customizations that are specific to their needs is what makes the CLR so adaptable to a variety of scenarios. Table 2-2 briefly describes all the managers in the CLR hosting API. (The primary interface for each manager is shown in boldface.)
Given this background, let's begin our tour of the hosting API by looking at how to initialize and load the CLR in a process. |
|