Fabio Gouw

Onde trabalho, não faz muito tempo que fomos questionados sobre boas práticas e o bom uso de assemblies .NET no GAC (Global Assembly Cache). Sinceramente, o melhor uso do GAC é não utilizá-lo, pelo menos no contexto que as aplicações aqui são desenvolvidas. As aplicações, com excessão das que são utilitários e frameworks, geralmente são isoladas no que se diz respeito a reaproveitamento de código. Então, o uso do GAC não se justifica para essa maioria dos casos. Umas das coisas legais que aprendi enquanto dava uma olhada no assunto foi utilizar melhor as configurações de runtime, mais especificamente em relação ao codebase. Com esta configuração, é possível indicar o caminho de um assembly que deve ser utilizado pela aplicação, estando ela onde estiver na máquina ou inclusive na rede! Com isso, acabou a desculpa de colocar um componente no GAC apenas porque a aplicação, seja ela windows ou web, não consegue encontrá-lo. GAC é para compartilhar, como o próprio nome diz. E como f

Finalmente consegui resolver o problema que estava tendo com o Windows Installer e o COM+ de uma forma aceitável. O Problema O problema inicial foi quando criei um instalador, utilizando o InstallShield, para empacotar um aplicativo que utilizamos onde trabalho, que havia sido migrado de .NET 1.1 para .NET 2.0. Este aplicativo é composto de componentes .NET 1.1 (para manter a compatibilidade com versões de sistemas que usam esse runtime), .NET 2.0 com windows services e COM+ (também para manter compatibilidade). A compatibilidade foi necessária para fazer com que os sistemas que utilizassem a versão em .NET 1.1 desse aplicativo pudessem passar a utilizar a nova, sem a necessidade de alterações em código. E para manter a compatibilidade, foi criado o pacote COM+ citado acima, para ser o divisor de águas entre os runtimes 1.1 e 2.0, permitindo as chamadas. Quando este pacote foi instalado nos servidores de componentes, a cada chamada do aplicativo, eram logados os eventos abaixo, além de