Usando servidores nativo COM do .NET
Esta seção descreve as opções disponível para o uso de componentes COM existentes de aplicativos .NET e descreve as vantagens e desvantagens de cada abordagem.Em geral, o método recomendado é de interoperabilidade C++.
Usando TLBIMP
The Windows Software Development Kit (SDK) Tipo Biblioteca Importer (Tlbimp.exe) is a tool that exposes a COM type library as an assembly called an interop assembly.Este assembly define equivalentes gerenciado ou wrappers para cada interface COM em uma biblioteca de determinado tipo.
Quando são chamados métodos para o assembly de interoperabilidade, uma transição não gerenciado para gerenciado é executada e o controle é passado para o componente COM.Da mesma forma, quando retorna a função de COM não gerenciada, uma transição não gerenciado para gerenciado é executada.Por padrão, o HRESULT COM é verificado para falha e uma exceção é lançada se o HRESULT não indicar êxito.Da mesma forma, consultas de inicialização e interface de componente COM são executadas pelo assembly de interoperabilidade e ocultas, portanto, o código de chamada.
Assemblies de interoperabilidade não substituam os componentes COM que eles representam, as funções não gerenciadas COM permanecem no componente COM, para que o componente deve ser instalado e registrado nos computadores de destino ou falha nas chamadas para o assembly de interoperabilidade.
Usando Tlbimp é a maneira mais fácil de usar um componente COM do código gerenciado, mas há algumas desvantagens sérias, especialmente para interfaces COM grandes e/ou complexos. Essas desvantagens são:
Tlbimp gera interfaces gerenciadas para cada interface COM na biblioteca de tipos. Não é possível suprimir esse comportamento, portanto, os assemblies resultantes podem ser muito grandes.(Por exemplo, a Tlbimp-geradas assembly de interoperabilidade para Mshtml.dll tiver mais de 8 MB.) Não há nenhuma maneira para ocultar uma interface destinado somente para uso no componente COM também.
Tlbimp oferece suporte a um número limitado de tipos de dados. Tipos sem suporte geralmente são importados para o mundo gerenciado sistema autônomo o tipo de IntPtr genérico, não seguros, necessidade de código de marshaling entediante e sujeito a erro para usar o assembly mas às vezes Tlbimp.exe não pode expor membros de uma interface em todos sistema autônomo.
Tlbimp gera um assembly de interoperabilidade separado, que deve ser implantado com o aplicativo final.
Se essas desvantagens são aceitáveis, consulte Como: Usar servidores COM nativo com TLBIMP Para obter um exemplo.
Modificando MSIL
As desvantagens de Tlbimp pode ser atenuada um pouco por desmontar o assembly de interoperabilidade — usando o Desassemblador do MSIL (ILDASM.exe) — edição MSIL remover definições de interface desnecessárias e substituir tipos de argumento e, em seguida, remontagem MSIL com o Assembler MSIL (Ilasm.exe). Esse processo é propenso a erros e requer conhecimento de MSIL, tipos não gerenciados e tipos .NET.Além disso, isso deve ser feita novamente se as interfaces COM forem atualizadas.
Interoperabilidade de C++
sistema autônomo desvantagens de Tlbimp — e de edição MSIL — pode ser evitado inteiramente no Visual C++ porque, diferentemente do Visual Basic e translation from VPE for Csharp, Visual C++ pode usar objetos COM diretamente usando sistema autônomo mecanismos COM usuais (sistema autônomo CoCreateInstance e QueryInterface). Isso é possível devido a recursos de interoperabilidade de C++ que fazem com que o compilador inserir automaticamente o código de transição para mover de funções gerenciadas para não gerenciado e vice-versa.
Usando a interoperabilidade de C++, componentes COM podem ser usados sistema autônomo eles são usados normalmente ou pode ser dispostas dentro de classes C++.Essas classes de wrapper são chamados de tempo de execução personalizada callable wrappers ou CRCWs e eles têm duas vantagens usando COM diretamente no código do aplicativo:
A classe resultante pode ser usada em idiomas Outros que o Visual C++.
Os detalhes da interface COM podem ser oculto do código de cliente gerenciado.Tipos de dados do .NET podem ser usados no lugar dos tipos nativo e os detalhes de marshaling de dados podem ser executados, de forma transparente, dentro do CRCW.
Usando o Visual C++ para encapsular interfaces COM é demonstrado no Como: Usar servidores COM nativo com CRCWs.
Independentemente do COM é usado diretamente ou por meio de um CRCW, tipos de argumento diferentes tipos blittable simples, devem ser empacotados.Para obter informações sobre marshaling de dados, consulte Usando a interoperabilidade de C++ (PInvoke implícita).
.gif "Observação") Observação: |
|---|
Aplicativos MFC devem ser inicializados sistema autônomo um único thread apartment (STA).Se você chamar CoInitializeEx in your InitInstance Substituir, especificar COINIT_APARTMENTTHREADED (em vez de COINIT_MULTITHREADED). Para obter mais informações, consulte PRB: Aplicativo MFC pára de responder quando você inicializar o aplicativo sistema autônomo um multithreaded apartment (828643) em http://suporte.Microsoft.com/padrão.aspx?scid=kb;en-US;828643. |