Usando retornos de chamada de componentes hospedados

Retornos de chamada de componentes hospedados são o que possibilitam a hospedagem. No entanto, é possível que o componente que você está hospedando tenha ativado outro contexto de ativação que ele usa para acessar plug-ins ou componentes próprios. Nesse caso, se o componente hospedado deixar um contexto de ativação na pilha que se refere ao seu próprio objeto COM, o aplicativo de hospedagem poderá chamar CoCreateInstance para obter um objeto que espera ser sua própria implementação e, em vez disso, receber o objeto do componente hospedado. Para evitar essa herança de contextos de ativação, um bom aplicativo de hospedagem deve ativar seu próprio contexto de ativação conhecido primeiro durante um retorno de chamada.

Considere o seguinte exemplo que protege o código do aplicativo de hospedagem:

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;
}

Isso garante que um contexto de ativação adequado seja definido antes de passar a solicitação para alguma implementação interna de Funct. Sua própria implementação pode ter a implementação real embutida, mas o método anterior garante uma interoperabilidade mais fácil apenas criando wrappers delegados. É recomendável usar um método semelhante ao expor retornos de chamada normais (não COM).