Quand et quand ne pas installer dans le GAC?

Question

Quand devriez-vous installer dans le GAC et quand ne devriez-vous pas? (En réalité, je parle d'installation sur la machine d'un client après l'achat de nos produits).

1. J'ai un assemblage qui ne sera utilisé qu'avec ma seule application (GAC ou no-GAC)?

2. J'ai un assemblage partagé par toutes mes applications (GAC ou non-GAC)?

3. Toutes mes applications peuvent utiliser différentes versions de mon assemblage (GAC ou non-GAC)?

Ce sont trois scénarios ... mais je suis sûr qu’il en existe d’autres. Je ne cherche pas nécessairement une réponse à ces trois questions seulement.

Une question similaire:

Était-ce utile?

Nous faire parvenir

La solution

Directives générales relatives aux États membres

1. non
2. non
3. non

GAC est en réalité un référentiel pour les bibliothèques .NET communes à Microsoft. Oui, ils permettent également aux développeurs de l'utiliser, mais en règle générale, si vous n'avez pas besoin de GAC, ne l'utilisez pas. garder les choses simples et locales si ça ne fait pas mal.

• Je considérerais GAC uniquement pour des raisons de performances. Par exemple, si vous avez d’énormes assemblys, essayez de les placer dans GAC et NGEN . Cela devrait augmenter considérablement les performances. Microsoft le fait pour tous les assemblys .NET Framework standard lors de l'installation (vous savez maintenant pourquoi cette installation prend autant de temps). Paint.NET le fait également (pour améliorer le temps de démarrage de leur application). Cependant, la plupart d’entre nous ne travaillons pas sur d’énormes frameworks ou sur des concurrents Photoshop, la plupart du temps, les gains de performances liés à l’assemblage dans GAC sont minimes. Il ne faut pas abandonner le simple déploiement x-copy.

• Certains développeurs peuvent utiliser GAC pour s'assurer que les utilisateurs disposant de privilèges insuffisants ne peuvent pas supprimer ou modifier leurs assemblys.

• Pour d’autres, c’est peut-être pour des raisons de gestion de versions, mais ici, vous devriez vraiment reconsidérer. Je ne vais pas répéter ce qui a déjà été dit, vous pouvez lire ici pourquoi .

Et n'oubliez pas qu'une fois que vous souhaitez déployer votre système dans GAC, votre installateur aura besoin de privilèges d'administrateur. Vous pouvez oublier le déploiement par simple clic, etc.

.

Answer 1

Directives générales relatives aux États membres

1. non
2. non
3. non

GAC est en réalité un référentiel pour les bibliothèques .NET communes à Microsoft. Oui, ils permettent également aux développeurs de l'utiliser, mais en règle générale, si vous n'avez pas besoin de GAC, ne l'utilisez pas. garder les choses simples et locales si ça ne fait pas mal.

• Je considérerais GAC uniquement pour des raisons de performances. Par exemple, si vous avez d’énormes assemblys, essayez de les placer dans GAC et NGEN . Cela devrait augmenter considérablement les performances. Microsoft le fait pour tous les assemblys .NET Framework standard lors de l'installation (vous savez maintenant pourquoi cette installation prend autant de temps). Paint.NET le fait également (pour améliorer le temps de démarrage de leur application). Cependant, la plupart d’entre nous ne travaillons pas sur d’énormes frameworks ou sur des concurrents Photoshop, la plupart du temps, les gains de performances liés à l’assemblage dans GAC sont minimes. Il ne faut pas abandonner le simple déploiement x-copy.

• Certains développeurs peuvent utiliser GAC pour s'assurer que les utilisateurs disposant de privilèges insuffisants ne peuvent pas supprimer ou modifier leurs assemblys.

• Pour d’autres, c’est peut-être pour des raisons de gestion de versions, mais ici, vous devriez vraiment reconsidérer. Je ne vais pas répéter ce qui a déjà été dit, vous pouvez lire ici pourquoi .

Et n'oubliez pas qu'une fois que vous souhaitez déployer votre système dans GAC, votre installateur aura besoin de privilèges d'administrateur. Vous pouvez oublier le déploiement par simple clic, etc.

.

Answer 2

Cas utiles pour GAC:

• Code appelable par COM - c’est-à-dire que vous souhaitez que du code non.NET puisse vous accéder sans vous occuper des dlls, etc.
• Composants gérés (COM +)
• Si vous écrivez du code si commun, il est utile d'utiliser GAC - principalement des composants de framework .NET, etc.
• Si vous souhaitez utiliser NGEN pour pré-JIT le code

À part ça, j'ai tendance à éviter le GAC comme la peste. Il est beaucoup plus facile de simplement déployer les dll nécessaires avec votre application via robocopy etc; cela donne et un déploiement facile.

Answer 3

Si vous installez des applications Web asp.net et que vous en êtes le propriétaire et que vous maîtrisez parfaitement la machine, il peut s'avérer judicieux de placer vos assemblages, ce que vous prévoyez partager des sites / instances Web dans le cache d'assembly global.

Si vous placez les assemblys dans le GAC, vous pouvez considérablement améliorer le temps de chargement initial et l'utilisation de la mémoire de l'application sur des serveurs comportant plusieurs instances des mêmes applications ASP.NET. Au moins, je l'ai vu sur nos serveurs avec des dizaines d'installations.

Answer 4

Si vous expédiez une bibliothèque réutilisable composée de plusieurs assemblys, mais que seuls quelques-uns d'entre eux forment une façade, vous pouvez envisager d'installer les assemblys dans GAC, si le package est installé sur les PC du développeur.

Imaginez, vous expédiez 6 assemblages, et un seul de ces 6 assemblages contient une façade - c’est-à-dire que les 5 autres ne sont utilisés que par la façade elle-même. Vous expédiez:

• MyProduct.Facade.dll : il s'agit du seul composant destiné aux développeurs
• MyProduct.Core.dll - utilisé par MyProduct.Facade.dll, mais non destiné à être utilisé par les développeurs
• MyProduct.Component1.dll - le même
• MyProduct.Component2.dll - le même
• ThirdParty.Lib1.dll - bibliothèque tierce utilisée par MyProduct.Component1.dll
• ThirdParty.Lib2.dll - le même
• etc.

Les

développeurs utilisant votre projet souhaitent référencer uniquement MyProduct.Facade.dll dans leurs propres projets. Mais lorsque leur projet s'exécute, il doit pouvoir charger tous les assemblages auxquels il fait référence, de manière récursive. Comment cela peut être réalisé? En général, ils doivent être disponibles dans le dossier Bin, dans GAC:

• Vous pouvez demander aux développeurs de localiser votre dossier d'installation et d'ajouter des références à tous les N ensembles que vous y avez installés. Cela garantira qu'ils seront copiés dans le dossier Bin pour être disponibles au moment de l'exécution.
• Vous pouvez installer le modèle de projet VS.NET contenant déjà ces 6 références . Un peu complexe, car vous devez injecter le chemin réel de vos assemblys dans ce modèle avant avant son installation. Cela ne peut être fait que par l’installateur, car ce chemin dépend du chemin d’installation.
• Vous pouvez demander aux développeurs de créer une étape de post-génération spéciale dans le fichier .csproj / .vbproj en copiant les dépendances nécessaires dans le dossier Bin. Les mêmes inconvénients.
• Enfin, vous pouvez installer tous vos assemblages dans GAC . Dans ce cas, les développeurs doivent ajouter la référence à MyProduct.Facade.dll à partir de leur projet. De toute façon, tout le reste sera disponible au moment de l'exécution.

Remarque: la dernière option ne vous oblige pas à faire de même lorsque vous envoyez le projet aux PC de production. Vous pouvez soit expédier tous les assemblys du dossier Bin, soit les installer dans GAC - tout dépend de vos souhaits.

La solution décrite montre donc l’avantage de placer des assemblages tiers dans GAC au cours du développement. Cela ne concerne pas la production.

Comme vous pouvez le constater, l’installation dans GAC est principalement destinée à résoudre le problème de l’emplacement des assemblys requis (dépendances). Si un assemblage est installé dans GAC, vous pouvez considérer qu'il existe & "À proximité &"; toute application. C’est comme ajouter un chemin à .exe dans votre variable PATH, mais dans & "Manière gérée &"; - bien sûr, cette description est plutôt simplifiée;)

Answer 5

Voici le lien de Chris Sells intitulé & "Evitez le GAC &";

.

https://sellsbrothers.com/12503

L'explication est assez longue, mais en bref, les deux cas qu'il identifie sont

1. Résoudre les bugs critiques sans toucher les applications concernées (et sans rien casser!)

2. Types de partage à l'exécution entre assemblys déployés séparément

Remarque: il existe un très long fil de discussion à la fin du message de Chris , très belle liste de commentaires.

Answer 6

d’abord si vous l’installez sur un ordinateur client, vous devrez ajouter une action personnalisée pour installer l’application dans le GAC et une autre lors de la suppression.

sur le cas A certainement pas GAC

dans le cas B, si votre bibliothèque change constamment, vous devrez ajouter chaque version de l'assembly dans le gac à chaque fois et effectuer la mise à jour vers cet assemblage

Dans le cas C, l’exécution côte à côte vous permet d’exécuter différentes versions d’assemblage sans avoir à ajouter quoi que ce soit pour différencier les versions.

Utilisé uniquement si vous en avez vraiment besoin

Answer 7

L'installation dans le GAC n'a de sens que si de nombreuses applications Web sur le même serveur partagent exactement les mêmes bibliothèques. Par exemple, sur un serveur Sharepoint, il peut y avoir des centaines de sites Web qui doivent tous partager le même composant WebPart. Dans ce cas, il est donc judicieux de déployer le composant WebPart compilé sur le GAC.