Verwenden von Rückrufen aus gehosteten Komponenten

Rückrufe von gehosteten Komponenten ermöglichen das Hosting. Es ist jedoch möglich, dass die Komponente, die Sie hosten, einen anderen Aktivierungskontext aktiviert hat, den sie für den Zugriff auf Plug-Ins oder eigene Komponenten verwendet. Wenn die gehostete Komponente in diesem Fall einen Aktivierungskontext auf dem Stapel hinterlässt, der auf ihr eigenes COM-Objekt verweist, ruft die Hostinganwendung möglicherweise CoCreateInstance auf, um ein Objekt abzurufen, von dem sie erwartet, dass es sich um eine eigene Implementierung handelt, und empfängt stattdessen das Objekt der gehosteten Komponente. Um diese Vererbung von Aktivierungskontexten zu verhindern, sollte eine gute Hostinganwendung zuerst während eines Rückrufs ihren eigenen bekannten Aktivierungskontext aktivieren.

Betrachten Sie das folgende Beispiel, das den Code der Hostinganwendung schützt:

HRESULT STDCALL 
CHostingAppFirewall::ITheInterface::FunctWrapper()
{
    ULONG_PTR ulpCookie;
    HRESULT hRes = E_FAIL;
    if (!ActivateActCtx(this->m_hHostingAppContext, &ulpCookie))
        return HRESULT_FROM_WIN32(GetLastError());
    __try 
        {
        hRes = this->m_ITheInterface->Funct();
    } 
        __finally 
        {
        if (!DeactivateActCtx(0, ulpCookie))
            hRes = HRESULT_FROM_WIN32(GetLastError());
    }
    return hRes;
}

Dadurch wird sichergestellt, dass ein ordnungsgemäßer Aktivierungskontext festgelegt wird, bevor die Anforderung an eine innere Implementierung von Funct übergeben wird. Ihre eigene Implementierung kann die tatsächliche Implementierung inline aufweisen, aber die vorherige Methode sorgt für eine einfachere Interoperabilität, indem nur delegierte Wrapper erstellt werden. Es wird empfohlen, beim Verfügbarmachen normaler Rückrufe (nicht COM) eine ähnliche Methode zu verwenden.