Runtime Callable Wrapper (RCW) escopo - processo ou domínio de aplicação?

Question

O que é o escopo da Runtime Callable Wrapper (RCW), ao fazer referência a objetos COM não gerenciados? De acordo com os documentos:

O tempo de execução cria exatamente um RCW para cada objecto COM, independentemente do número de referências que existem no esse objeto.

Se eu tivesse que "adivinhar" - essa explicação deve significar "um por processo", mas é realmente? Toda a documentação adicional será muito bem-vindos.

Meu aplicativo é executado em seu próprio domínio de aplicação (que é suplemento do Outlook), e eu gostaria de saber o que acontece se eu usar Marshal.ReleaseComObject (x) em um loop até que seja contagem chegar a 0 (como recomendado). Será que vai liberar referências de outros suplementos (em execução em outro domínio de aplicativo no mesmo processo Outlook)?

EDIT: Perfect - agora a confusão é ainda maior. Com base nas respostas 2 (de Lette e Ilya) temos 2 respostas diferentes. A MSDN doc oficial diz por processo (por ver. 2.0+), mas está faltando esta frase para ver. 1.1 do doc .

Ao mesmo tempo, no artigo de Mason Bendixen, ele diz que é por appdomain.

Como o seu artigo é velho (Abril de 2007), eu tenho enviar-lhe um e-mail pedindo esclarecimentos, mas se alguém tem de acrescentar algo, por favor.

Graças

Answer 1

Em gerenciado, temos um por domínio de aplicativo esconderijo mapeamento IUnknowns canônicas voltar ao RCWs. Quando um IUnknown entra no sistema (através de uma chamada marechal, por meio de activação, tal como um retorno parâmetro de uma chamada de método, etc.), vamos verificar o cache para ver se um RCW já existe para o objecto COM. E se um mapeamento de existir, uma referência para o RCW existente é retornado. Caso contrário, uma novo RCW é criado e um mapeamento de cache é adicionado.

de Mason

Answer 2

O artigo de blog Mason Bendixen que Ilya cita está correto: o RCW é delimitado para o AppDomain, não para o processo. I apenas pode supor que o tempo de execução mobilizável envoltório (MSDN 2,0) artigo estava falando "casualmente". Esse artigo não é necessariamente incorreta no sentido geral, porque é mais típico para executar usando apenas um único AppDomain, mas que a sentença não é tecnicamente preciso.

Quanto à sua pergunta específica:

"Eu gostaria de saber o que acontece se eu utilização Marshal.ReleaseComObject (x) numa laço até que seja contagem chegar a 0 (como recomendado). Será que vai liberar referências de outros suplementos (Rodando no outro domínio de aplicação no mesmo processo Outlook) ?? "

A resposta para isso depende de como você configurar o add-in. Em geral, se você não tomar precauções, então a resposta é sim, ele teria impacto das referências em outros add-ins que operam dentro do mesmo AppDomain. Mas desde que você estado que você está executando a partir de um AppDomain separado, então, não, não.

Há um COM Shim Assistente Versão 2.3.1 que você pode usar para isolar o add-in. A documentação para o Assistente de Shim COM pode ser encontrada aqui: Isolando Microsoft Office Extensions com o COM Versão Assistente Shim 2.3.1 .

O Assistente de Shim COM usa reflexão para construir um carregador de front-end COM personalizado que carrega o suplemento montagem dentro de um AppDomain separado. Isso cria segurança em dois aspectos:

(1) Usando um, personalizado ponto de entrada COM separado, o add-in é correctamente identificado separadamente por Microsoft Office a partir de todos os outros add-ins. Caso contrário, por padrão, todos os suplementos compartilhar o mesmo carregador mscoree.dll padrão. O problema com compartilhando o mesmo carregador é que se qualquer add-in tem um acidente, então mscoree.dll será identificado pelo Microsoft Office como a fonte do problema e não irá carregá-lo automaticamente na próxima vez. Você pode ligá-lo manualmente, mas o suplemento não carregar automaticamente na próxima vez devido a um problema em alguém do add-in!

(2) Ao carregar a sua montagem dentro de um domínio de aplicação em separado, os invólucros podem ser chamadas de tempo de execução (RCWs) são isoladas a partir de outros suplementos que são carregados no mesmo processo. Neste caso, se você chamar Marshal.ReleaseComObject (objeto) ou Marshal.FinalReleaseComObject (objeto), em seguida, você não estaria impactando qualquer outra pessoa add-ins. Mais importante, se qualquer um desses outros add-ins fazer tais chamadas, em seguida, o suplemento será protegido de ser corrompido. : -)

A desvantagem de usar o Assistente de Shim COM é que, operando a partir de um AppDomain separado há sobrecarga triagem extra. Eu não acredito que este deve ser perceptível para um Microsoft Outlook add-in. Ele pode ser um fator, no entanto, para algumas rotinas intensivas que têm lotes de chamadas para o modelo de objeto, como às vezes pode ser o caso de um add-in Microsoft Excel.

Você disse que você já está executando o add-in de um AppDomain separado. Se isso for verdade, então você já está isolado do Marshal.ReleaseComObject (objeto) e chamadas Marshal.FinalReleaseComObject (objeto) em relação a outros AppDomains. (Estou curioso para saber como você está fazendo isso, pela maneira ... Você criar explicitamente seu próprio AppDomain? O padrão add-in modelo no Visual Studio não não executado em AppDomain e cargas separado usando o mscoree.dll.)

Se você estiver criando seu próprio AppDomain, o código é isolado, mas sua identidade não pôde ser separado de outros suplementos, no entanto, como o add-in ainda estaria compartilhando o mscore padrãoe.dll carregador, a menos que você utilizados outros meios para resolver esta questão.

Espero que isso ajude ...

Answer 3

De acordo com os mesmos documentos:

O tempo de execução mantém uma única RCW por processo para cada objecto.

Eu penso que nós podemos seguramente assumir que objeto = exemplo , por isso, se os addins / AppDomains não mantém referências para a mesma instância, a chamada para won ReleaseComObject' t referências libertação para instâncias criadas em outros lugares.

Edit: A formulação dos documentos pode estar errado, como indicado em outros lugares . Se assim for, uma vez que o add-in está sendo executado em um AppDomain separado, você está na sorte. Mesmo se os diferentes add-ins referência a mesma instância (por exemplo, um objeto de mensagens no Outlook), ReleaseComObject chamado em sua AppDomain não causa RCWs em outros AppDomains a perder a referência a essa instância.