Clique aqui para ler todos os artigos desta edição
Global Assembly Cache
Instalando e versionando assemblies no GAC
Guinther Pauli
|
Este artigo discute |
Este artigo usa as seguintes tecnologias |
|
· Histórico das DLLs e “DLL Hell”; · Criando Class Libraries; · Acessando Class Libraries; · Versionando e assinando assemblies; · Instando assemblies no GAC; · Execução lado a lado. |
· C#, .NET Framework, Visual Studio 2005. |
O objetivo deste artigo é apresentar o GAC (Global Assembly Cache) e mostrar como você desenvolvedor pode tirar proveito dele para instalar e versionar seus assemblies desenvolvidos para o .NET Framework. Através de um exemplo prático passo a passo desenvolvido no Visual Studio 2005 (também pode ser feito no 2003), vamos construir uma Class Library em C# e aproveitar para conhecer todos os detalhes envolvidos no processo de distribuição de DLLs no GAC. Antes de começar nosso exemplo, vamos relembrar um pouco sobre DLLs para que você possa entender o porquê do surgimento do GAC.
Um pequeno histórico
Acredito que todo desenvolvedor Windows já precisou, mais cedo ou mais tarde, construir uma DLL. Bibliotecas de vínculo dinâmico (Dynamic Link Libraries) são utilizadas na plataforma Windows há anos e servem para os mais diferentes propósitos: compartilhamento de código binário, criação de extensão de aplicativos e plug-ins, modularização de aplicações, armazenamento de recursos (como ícones e imagens), biblioteca para uso geral (com funções acessadas por vários aplicativos), desenvolvimento de componentes COM e ActiveX Libraries, entre outros.
No .NET Framework, você pode criar uma DLL (chamada de Class Library) para os mais diferentes propósitos: hospedar classes de negócio, criar uma camada independente de acesso a dados, criar bibliotecas de funções e rotinas comuns e reutilizáveis, facilitar a distribuição e instalação de custom controls e componentes etc. Dessa forma, é fundamental que você saiba trabalhar com Assemblies e decidir qual a melhor forma de distribuição. O próprio .NET Framework é distribuído na forma de DLLs compartilhadas. Não fosse isso, cada aplicação (EXE) precisaria compilar o código do framework, o que aumentaria consideravelmente o tamanho dos arquivos a serem distribuídos. É por isso que aplicações .NET têm alguns poucos Kb.
O Windows internamente faz uso de DLLs, sendo esse o formato para armazenar importantes partes do sistema operacional: kernel32.dll, user32.dll, gdi32.dll são alguns exemplos. Desenvolvedores de aplicativos podem utilizar a API do Windows para se comunicar diretamente com DLLs nativas do Sistema Operacional ou mesmo DLLs específicas, usando DLLImport no caso do C#. O Windows Forms, por exemplo, é uma camada sobre as DLLs Win32 do S.O., nos abstraindo de detalhes específicos e do uso de tipos esotéricos da API, como PChar, Cardinal etc.
Como todos sabem, DLLs que precisam ser compartilhadas por vários aplicativos são colocadas no diretório de sistema do Windows. Aplicações então podem fazer a carga dinâmica ou estática da DLL, localizar um procedimento de entrada exportado, obter um ponteiro para o endereço da rotina e fazer a chamada (isso para DLLs Win32).
As coisas pareciam estar indo bem até que um aplicativo precisasse instalar uma nova versão de uma DLL. Por exemplo, instalamos um software chamado Foo1.exe que faz uso de rotinas armazenadas na biblioteca HellLibrary.DLL, que reside no System32. Fazemos o download de um segundo aplicativo, Foo2.exe, que possui uma versão mais atualizada da DLL e a sobrescreve durante a instalação. Ao executarmos novamente o aplicativo Foo1.exe, podemos ter algumas surpresas desagradáveis, como por exemplo a mostrada na Figura 1.
Figura 1. DLL Hell
Isso pode acontecer porque a nova versão da DLL teve um procedimento alterado, ou renomeado (a menos que o vínculo seja feito pelo índice, a simples alteração do nome de um procedimento fará a aplicação falhar). Em outras situações, a assinatura de um procedimento muda, por exemplo, podendo receber um novo parâmetro. Para que ...
