Entendendo o que são Assemblies, Class Libraries e GAC no Delphi Prism - Artigo ClubeDelphi 130

Um pequeno histórico

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.

 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 possa funcionar novamente precisamos recompilar toda a aplicação, o que muitas vezes é inviável. Por esse motivo as interfaces da OO são utilizadas amplamente quando se fala em integrar aplicativos, garantindo contratos imutáveis.

Outro erro comum é quando a própria biblioteca já não existe mais (quem não lembra do erro “Não foi possível encontrar a biblioteca de vínculo dinâmico ...”). Existia uma solução de contorno, muitas vezes era possível “enganar” o Windows simplesmente criando uma DLL vazia (a partir de um arquivo texto mesmo) com o nome da biblioteca que está faltando no disco, e a aplicação poderia então ser executada. Isso porque a carga, nesse caso, era feita estaticamente. A verificação da existência da DLL era feita no momento da inicialização, mas a aplicação poderia nem mesmo fazer uso das rotinas durante a execução.

Esse problema se tornou tão comum no Windows que costumamos chamá-lo de “DLL Hell”, ou “Inferno das DLLs”. Uma deficiência do Sistema Operacional que levou cerca de 10 anos para ser suprida. Algumas versões mais recentes do Windows resolvem isso mantendo arquivos de instalação que monitoram mudanças nessas DLLs.

Como o .NET acabou com o DLL Hell"