Quando e quando não para instalar no GAC?

StackOverflow https://stackoverflow.com/questions/498361

Pergunta

Quando você deve instalar no GAC e quando não deve? (Refiro -me, realmente, para instalar na máquina de um cliente quando eles adquiriram nossos produtos).

  1. Eu tenho uma montagem que só será usada com meu único aplicativo (GAC ou sem-GAC)?

  2. Eu tenho uma montagem que todos os meus aplicativos compartilham (GAC ou não-GAC)?

  3. Todas as minhas aplicações poderia Use versões diferentes da minha montagem (GAC ou não-GAC)?

Estes são três cenários ... mas tenho certeza de que há mais. Não estou necessariamente procurando uma resposta apenas para essas três perguntas.

Pergunta semelhante: Quais são as vantagens e desvantagens do uso do GAC?

Foi útil?

Solução

Diretrizes gerais de MS

  1. não
  2. não
  3. não

O GAC é realmente um repositório para as bibliotecas .NET Microsoft Common. Sim, eles permitem que os desenvolvedores o usem, mas, como regra geral, se você não precisar do GAC, não o use. Mantenha as coisas simples e locais se não dói.

  • Eu consideraria o GAC apenas por razões de desempenho, por exemplo, se você tiver algumas montagens enormes, tente colocá -las no GAC e Ngen eles. Deve aumentar significativamente o desempenho. A Microsoft faz isso para todos os conjuntos padrão do .NET da estrutura durante a instalação (agora você sabe por que essa instalação leva tanto tempo). O Paint.net também faz isso (para melhorar o tempo de inicialização do aplicativo). No entanto, a maioria de nós não trabalha em enormes estruturas ou concorrentes do Photoshop; portanto, na maioria das vezes, os ganhos de desempenho com a montagem no GAC são mínimos. Não vale a pena desistir da implantação simples do x-copy.

  • Alguns desenvolvedores podem usar o GAC para garantir que os usuários com privilégios insuficientes não possam excluir ou modificar suas montagens.

  • Para outros, pode ser por razões de versão, mas aqui você deve realmente reconsiderar. Não vou repetir o que já foi dito, Você pode ler aqui por que.

E não se esqueça que, uma vez que você quiser implantar no GAC, seu instalador precisará de privilégios de administrador, você pode esquecer a implantação de cliques, etc ...

Outras dicas

Casos úteis para GAC:

  • Código compatível-ou seja, você quer que algum código não
  • Componentes de serviço (Com+)
  • Se você está escrevendo código tão comum, é realmente significativo usar GAC - principalmente componentes da estrutura .NET etc.
  • Se você quiser usar Ngen Para pré-jit o código

Fora isso, eu tendem a evitar o GAC como a praga. É muito mais fácil implantar as DLLs necessárias com seu aplicativo via robocopy etc; Isso dá isolamento e fácil implantação.

Se você estiver instalando Aplicativos da Web ASP.NET E você é o proprietário e tem controle total sobre a máquina; em alguns casos Compartilhe em sites/instâncias da web no cache global de montagem.

Você pode melhorar drasticamente o tempo de carregamento inicial e o uso da memória do aplicativo em servidores que possuem várias instâncias múltiplas dos mesmos aplicativos ASP.NET se você colocar os conjuntos no GAC. Pelo menos eu vi isso em nossos servidores com dezenas de instalações.

Se você estiver enviando uma biblioteca reutilizável composta por vários conjuntos, mas apenas alguns deles formam uma fachada, considere instalar os conjuntos no GAC, se o pacote for instalado nos PCs do desenvolvedor.

Imagine, você envia 6 assembléias e apenas uma dessas 6 assembléias contém uma fachada - ou seja, outras 5 são usadas apenas pela fachada em si. Você envia:

  • MyProduct.facade.dll - Esse é o único componente destinado a ser usado pelos desenvolvedores
  • Myproduct.core.dll - usado por myproduct.facade.dll, mas não pretendido para ser usado por desenvolvedores
  • MyProduct.component1.dll - o mesmo
  • MyProduct.component2.dll - o mesmo
  • Terceira parte
  • Terceiros.lib2.dll - o mesmo
  • etc.

Os desenvolvedores que usam seu projeto gostariam de referir apenas MyProduct.facade.dll em seus próprios projetos. Mas quando o projeto é executado, ele deve ser capaz de carregar todos os conjuntos que ele faz referência - recursivamente. Como isso pode ser alcançado? Em geral, eles devem estar disponíveis na pasta BIN, no GAC:

  • Você pode pedir aos desenvolvedores que localizem sua pasta de instalação e Adicione referências a todos n Assembléias que você colocou lá. Isso garantirá que eles sejam copiados na pasta BIN para estar disponível em tempo de execução.
  • Você pode instalar o modelo de projeto vs.net já contendo essas 6 referências. Um pouco complexo, já que você deveria injetar O caminho real para suas montagens nesse modelo antes da sua instalação. Isso pode ser feito apenas pelo instalador, pois esse caminho depende do caminho da instalação.
  • Você pode pedir aos desenvolvedores que Crie um arquivo especial pós-construção no arquivo .csproj / .vbProj copiando as dependências necessárias para a pasta BIN. As mesmas desvantagens.
  • Finalmente, você pode Instale todos os seus conjuntos em GAC. Nesse caso, os desenvolvedores devem adicionar a referência apenas ao myProduct.facade.dll do projeto. Todo o resto estará disponível no tempo de execução de qualquer maneira.

Nota: A última opção não faz você fazer o mesmo enquanto envia o projeto para os PCs de produção. Você pode enviar todas as montagens da pasta BIN ou instalá -las no GAC - tudo depende de todo o seu desejo.

Portanto, a solução descrita mostra a vantagem de colocar os conjuntos de terceiros no GAC durante o desenvolvimento. Não está relacionado à produção.

Como você pode encontrar, a instalação no GAC é destinada principalmente a resolver o problema da localização dos conjuntos necessários (dependências). Se uma montagem estiver instalada no GAC, você poderá considerar que existe "próximo" qualquer aplicativo. É como adicionar caminho ao .exe à sua variável de caminho, mas de "maneira gerenciada". - Claro, isso é uma descrição bastante simplificada;)

Aqui está o link de Chris Sells chamado "Evite o GAC"

https://sellsbrothers.com/12503

A explicação é bastante longa, mas em suma, os dois casos que ele identifica são

  1. Corrigindo bugs críticos sem tocar nos aplicativos afetados (e sem quebrar nada!)

  2. Tipos de compartilhamento em tempo de execução entre as montagens implantadas separadamente

Nota: Há um tópico de discussão muito longo No final do post de Chris, lista muito boa de comentários.

Primeiro, se você estiver instalando isso em uma máquina cliente, precisará adicionar uma ação personalizada para instalar o aplicativo no GAC e outro ao remover.

no caso definitivamente não gac

No caso B, se sua biblioteca mudar constantemente, você precisará adicionar todas as versões da assembléia ao GAC toda vez e atualizar para essa montagem ocorrer

No caso C, a execução lado a lado permite executar diferentes versões de montagem e não precisa adicionar nada para diferenciar as versões.

Usado apenas se você realmente precisa

Faz sentido instalar no GAC se muitos aplicativos da Web no mesmo servidor compartilharem exatamente as mesmas bibliotecas. Por exemplo, em um servidor SharePoint, pode haver centenas de sites que precisam compartilhar a mesma Web Part; portanto, neste caso, faz sentido implantar a Web Part compilada no GAC.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top