O.NET 4.0 tem um novo GAC, por quê?




.net-4.0 (2)

Não faz muito sentido, o GAC original já era capaz de armazenar diferentes versões de montagens. E há poucas razões para supor que um programa referirá acidentalmente a montagem errada, todos os assemblies do .NET 4 obtiveram a [AssemblyVersion] ampliada para 4.0.0.0. O novo recurso lado a lado em processo não deve alterar isso.

Meu palpite: já havia muitos projetos do .NET por aí que quebraram a regra "nunca fazer referência a nada no GAC diretamente". Eu já vi isso feito neste site várias vezes.

Apenas uma maneira de evitar esses projetos: mover o GAC. O Back-compat é sagrado na Microsoft.

%windir%\Microsoft.NET\assembly\ é o novo GAC . Isso significa que agora temos que gerenciar dois GACs, um para aplicativos .NET 2.0-3.5 e outro para aplicativos .NET 4.0?

A questão é, por quê?


Sim, já que há dois GAC (Global Assembly Cache) distintos, você terá que gerenciar cada um deles individualmente.

No .NET Framework 4.0, o GAC passou por algumas alterações. O GAC foi dividido em dois, um para cada CLR.

A versão CLR usada para o .NET Framework 2.0 e o .NET Framework 3.5 é CLR 2.0. Não houve necessidade nas duas versões anteriores da estrutura para dividir o GAC. O problema de quebrar aplicativos mais antigos no Net Framework 4.0.

Para evitar problemas entre o CLR 2.0 e o CLR 4.0, o GAC agora é dividido em GACs privados para cada tempo de execução. A principal alteração é que os aplicativos CLR v2.0 agora não podem ver os assemblies do CLR v4.0 no GAC.

Source

Por quê?

Parece ser porque houve uma alteração no CLR no .NET 4.0, mas não no 2.0 para 3.5. A mesma coisa aconteceu com o 1.1 a 2.0 CLR. Parece que o GAC tem a capacidade de armazenar diferentes versões de conjuntos, desde que sejam do mesmo CLR. Eles não querem quebrar aplicativos antigos.

Consulte as seguintes informações no MSDN sobre as alterações do GAC na versão 4.0 .

Por exemplo, se o .NET 1.1 e o .NET 2.0 compartilhassem o mesmo GAC, um aplicativo .NET 1.1, carregando um assembly desse GAC compartilhado, poderia obter assemblies .NET 2.0, quebrando assim o aplicativo .NET 1.1

A versão CLR usada para o .NET Framework 2.0 e o .NET Framework 3.5 é CLR 2.0. Como resultado disso, não houve necessidade nas duas versões anteriores do framework para dividir o GAC. O problema de interromper os aplicativos antigos (neste caso, .NET 2.0) ressurge no Net Framework 4.0 no ponto em que o CLR 4.0 é lançado. Portanto, para evitar problemas de interferência entre o CLR 2.0 e o CLR 4.0, o GAC agora é dividido em GACs privados para cada tempo de execução.

Como o CLR é atualizado em versões futuras, você pode esperar a mesma coisa. Se apenas o idioma mudar, você poderá usar o mesmo GAC.





gac