Verwenden der Aktivierungskontext-API

Anwendungen können einen Aktivierungskontext verwalten, indem sie die Aktivierungskontextfunktionen direkt aufrufen. Aktivierungskontexte sind Datenstrukturen im Arbeitsspeicher. Das System kann die Informationen im Aktivierungskontext verwenden, um eine Anwendung zum Laden einer bestimmten DLL-Version, eines COM-Objekts instance oder einer benutzerdefinierten Fensterversion umzuleiten. Weitere Informationen finden Sie unter Referenz zum Aktivierungskontext.

Die Anwendungsprogrammierschnittstelle (API) kann verwendet werden, um den Aktivierungskontext zu verwalten und versionsspezifische Objekte mit Manifesten zu erstellen. Die folgenden beiden Szenarien veranschaulichen, wie eine Anwendung einen Aktivierungskontext verwalten kann, indem sie die Aktivierungskontextfunktionen direkt aufruft. In den meisten Fällen wird der Aktivierungskontext jedoch vom System verwaltet. Anwendungsentwickler und Assemblyanbieter müssen in der Regel nicht den Stapel aufrufen, um den Aktivierungskontext zu verwalten.

• Prozesse und Anwendungen, die Indirektungs- oder Verteilungsebenen implementieren.

  Beispielsweise ein Benutzer, der Aktivierungskontexte in der Ereignisschleife verwaltet. Jedes Mal, wenn auf das Fenster zugegriffen wird, z. B. durch Bewegen der Maus über das Fenster, wird ActivateActCtx aufgerufen, wodurch der aktuelle Aktivierungskontext für die Ressource aktiviert wird, wie im folgenden Codefragment gezeigt.

HANDLE hActCtx;  
CreateWindow();  
...  
GetCurrentActCtx(&ActCtx);  
...  
ReleaseActCtx(&ActCtx);  

Im folgenden Codefragment aktiviert die API-Funktion die entsprechenden Aktivierungskontexte, bevor CallWindowProc aufgerufen wird. Wenn CallWindowProc aufgerufen wird, wird dieser Kontext verwendet, um eine Nachricht an Windows zu übergeben. Wenn alle Ressourcenvorgänge abgeschlossen sind, deaktiviert die Funktion den Kontext.

ULONG_PTR ulpCookie;  
HANDLE hActCtx;  
if(ActivateActCtx(hActCtx, &ulpCookie))  
{  
    ...  
    CallWindowProc(...);  
    ...  
    DeactivateActCtx(0, ulpCookie);  
}

• Delegator-Dispatch-Schicht.

  Dieses Szenario gilt für Manager, die mehrere Entitäten mit einer gemeinsamen API-Schicht verwalten, z. B. einem Treiber-Manager. Obwohl es noch nicht implementiert wurde, wäre ein Beispiel dafür der ODBC-Treiber.

  In diesem Szenario kann die mittlere Ebene Assemblybindungen verarbeiten. Um den versionsspezifischen Bindungstreiber abzurufen, müssen Herausgeber ein Manifest bereitstellen und Abhängigkeiten von bestimmten Komponenten in diesem Manifest angeben. Die Basisanwendung bindet nicht dynamisch an die Komponenten. Zur Laufzeit verwaltet der Treiber-Manager die Aufrufe. Wenn der ODBC-Treiber basierend auf der Verbindungszeichenfolge aufgerufen wird, lädt er den entsprechenden Treiber. Anschließend wird der Aktivierungskontext mithilfe der Informationen in der Assemblymanifestdatei erstellt.

  Ohne das Manifest besteht die Standardaktion für den Treiber darin, denselben Kontext wie von der Anwendung angegeben zu verwenden– in diesem Beispiel Version 2 von MSVCRT. Da ein Manifest vorhanden ist, wird ein separater Aktivierungskontext eingerichtet. Wenn der ODBC-Treiber ausgeführt wird, wird er an Version 1 der MSVCRT-Assembly gebunden.

  Jedes Mal, wenn der Treiber-Manager die Verteilungsebene aufruft, z. B. um den nächsten Datensatz abzurufen, verwendet er die entsprechenden Assemblys basierend auf dem Aktivierungskontext. Das folgende Codefragment veranschaulicht dies.

HANDLE hActCtx;  
ULONG_PTR ulpCookie;  
ACTCTX ActCtxToCreate = {...};  
hActCtx = CreateActCtx(&ActCtxToCreate);  
...;  
if (ActivateActCtx(hActCtx, &ulpCookie))  
{  
    ...  
    ConnectDb(...);  
    DeactivateActCtx(0, ulpCookie);  
}  
... 
ReleaseActCtx(hActCtx);