GAC vs. <codeBase>

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 fazer com que o runtime encontre o assembly? Simplesmente adicionando a seguinte configuração ao arquivo config:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="CodebaseLib"
                                    publicKeyToken="72eb1259ccc328b1"
                                    culture="neutral" />
                <codeBase version="1.0.0.0"
                          href="file://D:\Projetos\Testes\TesteCodebase\CodebaseLib\bin\Debug\CodebaseLib.dll"/>
            </dependentAssembly>
        </assemblyBinding>
    </runtime>
</configuration>

Cada assembly que precisa ser encontrado deve ter uma tag dependentAssembly, contendo as tags assemblyIdentity e codeBase. A própria configuração é auto-explicativa: com assemblyIdentity, se identifica o componente, informando o nome, a cultura, o publicKeyToken (no caso de componentes com strong name); codeBase informa a versão e onde encontrar o componente.

Aqui cabem duas observações:

  1. href pode fazer referência tanto a um arquivo em disco como um arquivo na internet (poderia ser http://www.meusite.com.br/CodebaseLib.dll).
  2. Caso o componente tenha strong name, então ele pode se localizar em qualquer lugar; já se ele não possuir então deve estar em um subdiretório do diretório da aplicação.

[]’s

Comentários

Postagens mais visitadas deste blog

Trocando configurações padrão do Live TIM

Uma proposta de Clean Architecure com Modelo de Atores

Testes automatizados em sistemas autenticados com certificados digitais, usando Selenium e PhantomJS