Marshaling para Interoperabilidade

A interoperabilidade gerencia como os dados são passados em argumentos de método e valores de retorno entre memória gerenciada e não gerenciada durante chamadas. A interoperabilidade de marshalling é uma atividade em tempo de execução realizada pelo serviço de marshalling da common language runtime.

A maioria dos tipos de dados tem representações comuns na memória gerenciada e não gerenciada. O marshaller de interoperabilidade gestiona esses tipos para você. Outros tipos podem ser ambíguos ou não representados na memória gerenciada.

Um tipo ambíguo pode ter várias representações não gerenciadas que mapeiam para um único tipo gerenciado ou informações de tipo ausentes, como o tamanho de uma matriz. Para tipos ambíguos, o marshaller fornece uma representação padrão e representações alternativas onde existem várias representações. Você pode fornecer instruções explícitas ao marshaller sobre como processar um tipo ambíguo.

Modelos de invocação de plataforma e interoperabilidade COM

O common language runtime fornece dois mecanismos para interoperar com código não gerenciado:

• A invocação de plataforma (P/Invoke), que permite que o código gerido chame funções exportadas de uma biblioteca não gerida.
• Interoperabilidade COM, que permite que o código gerenciado interaja com objetos COM (Component Object Model) por meio de interfaces.

Tanto a invocação de plataforma como a interoperabilidade COM utilizam o processo de marshalling para transferir com precisão os argumentos do método entre o chamador e o destinatário, e vice-versa, quando necessário. Como mostra a ilustração a seguir, uma chamada de método de invocação da plataforma flui de código gerido para código não gerido e nunca o contrário, exceto quando funções de retorno de chamada estão envolvidas. Embora as chamadas de invocação de plataforma possam fluir apenas de código gerenciado para não gerenciado, os dados podem fluir em ambas as direções como parâmetros de entrada ou saída. As chamadas do método de interoperabilidade COM podem fluir em qualquer direção.

No nível mais baixo, ambos os mecanismos utilizam o mesmo serviço de interoperabilidade; no entanto, certos tipos de dados são suportados exclusivamente pela interoperabilidade COM ou pela invocação da plataforma. Para obter detalhes, consulte Comportamento de empacotamento padrão.

Marshalling e Apartamentos COM

O marshaller de interoperabilidade converte dados entre o heap do Common Language Runtime e o heap não gerenciado. O marshalling ocorre sempre que o chamador e o destinatário não podem operar na mesma instância de dados. O "interop marshaller" torna possível que o chamador e o destinatário aparentem estar a operar nos mesmos dados, mesmo que tenham a sua própria cópia dos dados.

A COM também possui um marshaler que gere os dados entre apartamentos ou processos COM distintos. Ao comunicar entre código gerenciado e não gerenciado dentro do mesmo compartimento COM, o marshaller de interoperabilidade é o único marshaller envolvido. Ao chamar entre código gerenciado e código não gerenciado em um apartamento COM diferente ou em um processo diferente, tanto o marshaller de interoperabilidade quanto o marshaller COM estão envolvidos.

Clientes COM e Servidores Geridos

Um servidor gerenciado exportado com uma biblioteca de tipos registrada pelo Regasm.exe (Assembly Registration Tool) tem uma ThreadingModel entrada do Registro definida como Both. Esse valor indica que o servidor pode ser ativado em um apartamento single-threaded (STA) ou um apartamento multithreaded (MTA). O objeto de servidor é criado no mesmo apartamento que seu chamador, conforme mostrado na tabela a seguir:

Cliente COM	Servidor .NET	Requisitos de marshaling
STA	Both torna-se STA.	Coordenação dentro do mesmo apartamento.
MTA	Both torna-se MTA.	Coordenação dentro do mesmo apartamento.

Como o cliente e o servidor estão no mesmo apartamento, o serviço de interoperabilidade organiza automaticamente todos os dados. A ilustração a seguir mostra o serviço de interoperabilidade operando entre pilhas gerenciadas e não gerenciadas dentro do mesmo apartamento no estilo COM.

Se você planeja exportar um servidor gerenciado, esteja ciente de que o cliente COM determina o apartamento do servidor. Um servidor gerenciado chamado por um cliente COM inicializado em um MTA deve garantir a segurança do thread.

Clientes Gerenciados e Servidores COM

A configuração padrão para apartamentos de cliente gerenciados é MTA; no entanto, o tipo de aplicativo do cliente .NET pode alterar a configuração padrão. Por exemplo, uma configuração de apartamento de cliente do Visual Basic é STA. Você pode usar o System.STAThreadAttribute, o System.MTAThreadAttribute, a Thread.ApartmentState propriedade ou a Page.AspCompatMode propriedade para examinar e alterar a configuração do apartamento de um cliente gerenciado.

O autor do componente define a afinidade de thread de um servidor COM. A tabela a seguir mostra as combinações de modelos de apartamento para clientes .NET e servidores COM. Mostra também os requisitos de agrupamento resultantes para as combinações.

Cliente .NET	Servidor COM	Requisitos de marshaling
MTA (padrão)	MTA STA	Agrupamento de interoperabilidade. Interoperabilidade e organização COM.
STA	MTA STA	Interoperabilidade e organização COM. Agrupamento de interoperabilidade.

Quando um cliente gerenciado e um servidor não gerenciado estão no mesmo apartamento, o serviço de interoperabilidade organiza todos os dados. No entanto, quando cliente e servidor são inicializados em compartimentos diferentes, o empacotamento COM também é necessário. A ilustração a seguir mostra os elementos de uma chamada entre apartamentos:

Para a interligação entre apartamentos, pode-se fazer o seguinte:

• Aceite a sobrecarga do encaminhamento entre apartamentos, que é notável apenas quando há muitas chamadas através da fronteira. Você deve registrar a biblioteca de tipos do componente COM para que as chamadas atravessem com êxito o limite do apartamento.

• Altere o thread principal definindo o thread do cliente como STA ou MTA. Por exemplo, se o cliente C# invocar muitos componentes STA COM, poderá evitar a serialização entre apartamentos ao definir o thread principal como STA.

  Observação

  Uma vez que o thread de um cliente C# é definido como STA, as chamadas para componentes MTA COM exigirão empacotamento entre apartamentos.

Para obter instruções sobre como selecionar explicitamente um modelo de apartamento, consulte Threading gerenciado e não gerenciado.

Marshalling Chamadas Remotas

Tal como acontece com o empacotamento entre apartamentos, o agrupamento COM está envolvido em cada chamada entre código gerenciado e não gerenciado sempre que os objetos residem em processos separados. Por exemplo:

• Um cliente COM que invoca um servidor gerenciado em um host remoto usa COM distribuído (DCOM).
• Um cliente gerenciado que invoca um servidor COM em um host remoto usa DCOM.

A ilustração a seguir mostra como o interop marshalling e o COM marshalling fornecem canais de comunicação através dos limites do processo e do host:

Preservando a identidade

O common language runtime preserva a identidade de referências gerenciadas e não gerenciadas. A ilustração a seguir mostra o fluxo de referências diretas não gerenciadas (linha superior) e referências gerenciadas diretas (linha inferior) entre os limites do processo e do host.

Nesta ilustração:

• Um cliente não gerenciado obtém uma referência a um objeto COM de um objeto gerenciado que obtém essa referência de um host remoto. O mecanismo de comunicação remota é DCOM.

• Um cliente gerenciado obtém uma referência a um objeto gerenciado de um objeto COM que obtém essa referência de um host remoto. O mecanismo de comunicação remota é DCOM.

  Observação

  A biblioteca de tipos exportados do servidor gerenciado deve ser registrada.

O número de limites do processo entre chamador e destinatário é irrelevante; A mesma referência direta ocorre para chamadas dentro e fora do processo.

Comunicação remota gerenciada

O tempo de execução também fornece comunicação remota gerenciada, que você pode usar para estabelecer um canal de comunicação entre objetos gerenciados através dos limites do processo e do host. A comunicação remota gerenciada pode acomodar um firewall entre os componentes de comunicação, como mostra a ilustração a seguir:

Chamadas remotas através de firewalls usando SOAP ou a classe TcpChannel

Algumas chamadas não gerenciadas podem ser canalizadas por meio de SOAP, como as chamadas entre componentes atendidos e COM.

Tópicos relacionados

Título	Descrição
Comportamento de Marshalling Padrão	Descreve as regras que o serviço de interoperabilidade usa para organizar dados.
Organização de Dados com Invocação de Plataforma	Descreve como declarar parâmetros de método e passar argumentos para funções exportadas por bibliotecas não gerenciadas.
Processamento de dados com integração COM	Descreve como personalizar wrappers COM para alterar o comportamento de empacotamento.
Como: Migrar Managed-Code DCOM para WCF	Descreve como migrar do DCOM para o WCF.
Como mapear HRESULTs e Exceções	Descreve como mapear exceções personalizadas para HRESULTs e fornece o mapeamento completo de cada HRESULT para sua classe de exceção comparável no .NET Framework.
Interoperando usando tipos genéricos	Descreve quais ações são suportadas ao usar tipos genéricos para interoperabilidade COM.
Interoperando com código não gerenciado	Descreve os serviços de interoperabilidade fornecidos pelo Common Language Runtime.
Interoperabilidade COM avançada	Fornece links para mais informações sobre como incorporar componentes COM em seu aplicativo .NET Framework.
Considerações de design para interoperação	Fornece dicas para escrever componentes COM integrados.

Referência

System.Runtime.InteropServices