Usando retornos de chamada de componentes hospedados

Retornos de chamada de componentes hospedados são o que tornam a hospedagem possível. 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 refira ao seu próprio objeto COM, o aplicativo anfitrião 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, uma boa aplicação de hospedagem deve ativar primeiro o seu próprio contexto de ativação bem conhecido durante um callback.

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 do 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. Recomenda-se usar um método semelhante ao expor retornos de chamada normais (não COM).