Investigando oportunidades para otimizar um componente, experimentei definir métodos que não solicitam dados (em arrays etc.) como argumentos mas sim instâncias de IStream, e me deparei com um problema interessante: interoperabilidade com .NET.
Usar componentes COM em programas .NET não é particularmente difícil; no Visual Studio, é possível adicionar componentes COM como referências no projeto.
Se o componente for capaz de Automation, é possível usar a ferramenta tlbimp.exe para gerar manualmente um callable wrapper para o componente, que, se eu entendi as coisas corretamente, não precisa ser distribuído com a aplicação.
Porém, todos os métodos que eu aprendi tem essa peculiaridade: eles parecem assumir que um componente não usa interfaces definidas por outros componentes -- como, por exemplo, declarando parâmetros com tipo IStream, uma interface definida pelo sistema.
Pelo método do callable wrapper, a ferramenta assume que as interfaces mencionadas integram o componente (ou a type library) e portanto geram uma interface .NET correspondente. No meu caso, o método causava a geração de uma nova interface IStream, ao invés de reusar a definição pré-existente em System.Runtime.InteropServices.ComTypes.
Ora, reusar uma interface como IStream é interessante justamente para permitir reuso de instâncias de IStream pré-definidas no ambiente do usuário. Meu componente permitiria, por exemplo, um script Visual Basic usar MDAC para criar streams em memória e usá-los.
Qual é a solução recomendada para esses casos, então? Ora, surrealmente, a MSDN sugere decompilar o callable wrapper com ildasm.exe, modificar o texto CIL e recompilar isto com ilasm.exe. O objetivo da modificação é remover as interfaces geradas inutilmente e substituir nas listas de argumentos e retornos referências para os tipos certos.
Tendo me acostumado com a idéia de estar prestes a escrever assembler de .NET, numa espécia de reviravolta na história da programação, pensei nos efeitos colaterais sobre meu processo completo de construção.
Em primeiro lugar, desisti de absorver o processo inteiro como sugerido e simplesmente adicionei o texto CIL modificado no Subversion. Agora, posso dizer que o nosso projeto inclui até módulos em assembler, e impressionar os estagiários.
O segundo lugar me fez demorar mais: o Visual Studio não conhece arquivos *.il. Meu objetivo é usar o callable wrapper pelo mecanismo de referências do Visual Studio em um projeto de teste de unidade. Experimentei usar Class Library Projects em C++ e C# juntamente com o mecanismo de Custom Build sem sucesso.
Felizmente, isso é possível com um Makefile Project. Este tipo de projeto permitiu a construção de um assembly .NET a partir de um único fonte em CIL (mais um arquivo de recursos) usando ilasm.exe nas regras Build e Rebuild. Definindo a regra Output corretamente, o projeto de teste de unidade foi capaz de incluir o produto gerado pelo Makefile Project como esperado.
Compreendo que uma ferramenta como tlbimp.exe não possa fazer milagre diante de componentes usando interfaces arbitrárias; porém, me parece preguiça não resolver ao menos o caso das interfaces definidas pelo próprio Windows.
Usar componentes COM em programas .NET não é particularmente difícil; no Visual Studio, é possível adicionar componentes COM como referências no projeto.
Se o componente for capaz de Automation, é possível usar a ferramenta tlbimp.exe para gerar manualmente um callable wrapper para o componente, que, se eu entendi as coisas corretamente, não precisa ser distribuído com a aplicação.
Porém, todos os métodos que eu aprendi tem essa peculiaridade: eles parecem assumir que um componente não usa interfaces definidas por outros componentes -- como, por exemplo, declarando parâmetros com tipo IStream, uma interface definida pelo sistema.
Pelo método do callable wrapper, a ferramenta assume que as interfaces mencionadas integram o componente (ou a type library) e portanto geram uma interface .NET correspondente. No meu caso, o método causava a geração de uma nova interface IStream, ao invés de reusar a definição pré-existente em System.Runtime.InteropServices.ComTypes.
Ora, reusar uma interface como IStream é interessante justamente para permitir reuso de instâncias de IStream pré-definidas no ambiente do usuário. Meu componente permitiria, por exemplo, um script Visual Basic usar MDAC para criar streams em memória e usá-los.
Qual é a solução recomendada para esses casos, então? Ora, surrealmente, a MSDN sugere decompilar o callable wrapper com ildasm.exe, modificar o texto CIL e recompilar isto com ilasm.exe. O objetivo da modificação é remover as interfaces geradas inutilmente e substituir nas listas de argumentos e retornos referências para os tipos certos.
Tendo me acostumado com a idéia de estar prestes a escrever assembler de .NET, numa espécia de reviravolta na história da programação, pensei nos efeitos colaterais sobre meu processo completo de construção.
Em primeiro lugar, desisti de absorver o processo inteiro como sugerido e simplesmente adicionei o texto CIL modificado no Subversion. Agora, posso dizer que o nosso projeto inclui até módulos em assembler, e impressionar os estagiários.
O segundo lugar me fez demorar mais: o Visual Studio não conhece arquivos *.il. Meu objetivo é usar o callable wrapper pelo mecanismo de referências do Visual Studio em um projeto de teste de unidade. Experimentei usar Class Library Projects em C++ e C# juntamente com o mecanismo de Custom Build sem sucesso.
Felizmente, isso é possível com um Makefile Project. Este tipo de projeto permitiu a construção de um assembly .NET a partir de um único fonte em CIL (mais um arquivo de recursos) usando ilasm.exe nas regras Build e Rebuild. Definindo a regra Output corretamente, o projeto de teste de unidade foi capaz de incluir o produto gerado pelo Makefile Project como esperado.
Compreendo que uma ferramenta como tlbimp.exe não possa fazer milagre diante de componentes usando interfaces arbitrárias; porém, me parece preguiça não resolver ao menos o caso das interfaces definidas pelo próprio Windows.
Comentários
Postar um comentário