Este artigo apresenta uma visão geral sobre Assemblies, versionamento de DLLs e GAC (Global Assembly Cache) na plataforma .NET, usando o Delphi Prism.
Para que serve
Um assembly é uma unidade básica gerada pela compilação de aplicações no .NET. Servem para facilmente distribuir módulos e executáveis que podem ser versionados no GAC. O GAC por sua vez serve para terminar com o problema existente de múltiplas versões da mesma DLL rodando no S.O.
Em que situação o tema é útil
É útil na distribuição de aplicações que fazem uso de assemblies compartilhados, de forma que o CLR (Common Language Runtime) através do GAC gerencia quem deve acessar o que no S.O., independente da localização física dos arquivos no disco.
GAC, Assemblies e Class Libraries
O objetivo deste artigo é apresentar o GAC (Global Assembly Cache) e mostrar como você desenvolvedor pode tirar proveito dele para instalar e versionar assemblies desenvolvidos para o .NET Framework com Delphi Prism. Através de um exemplo prático desenvolvido no Visual Studio 2010, vamos construir uma Class Library em Delphi Prism 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.
Acredito que todo desenvolvedor Delphi 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 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. Algo semelhante a compilar um projeto Win32 com a opção “Build with runtime packages”.
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 .NET. A tecnologia 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. Exatamente como faz a VCL no Win32.
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 Foo1.exe ...
