Quand et quand ne pas l'installer dans le GAC?

Question

Quand devriez-vous installer dans le GAC et quand devez-vous pas? (Je fais référence, vraiment, pour l'installation sur la machine d'un client lors de l'achat de notre produit(s)).

1. J'ai un montage qui est uniquement destiné à être utilisé avec mon une application (GAC ou de non-GAC)?

2. J'ai une assemblée que toutes mes applications partagent GAC (ou de non-GAC)?

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

Ces trois scénarios... mais je suis sûr qu'il ya plus. Je ne suis pas nécessairement à la recherche d'une réponse à ces trois questions.

Même question: Quels sont les avantages et les inconvénients de l'utilisation de la GAC?

Answer 1

Général MME des lignes directrices

1. pas de
2. pas de
3. pas de

GAC est vraiment un référentiel pour Microsoft commun .Bibliothèques NET. Oui, ils permettent aux développeurs de l'utiliser aussi, mais en règle générale, si vous n'avez pas besoin GAC, ne l'utilisez pas. garder les choses simples et local, même si il ne fait pas de mal.

• Je considère GAC seulement pour des raisons de performances, par exemple, si vous avez de grandes assemblées, essayez de les placer dans le GAC et NGEN eux. Il devrait augmenter de manière significative les performances. Microsoft est-il pour tous les standards .NET framework assemblées lors de l'installation (maintenant vous savez pourquoi cette installation prend tellement 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'immenses cadres ou photoshop concurrents, donc la plupart du temps, les gains de performance d'avoir l'assembly dans le GAC sont minimes. Pas la peine d'abandonner x simple copie de déploiement.

• Certains développeurs peuvent utiliser GAC afin de s'assurer que les utilisateurs avec des privilèges insuffisants ne pouvez pas supprimer ou modifier leurs assemblées.

• Pour d'autres, ce sera pour la gestion des versions de raisons, mais là, vous devriez vraiment reconsidérer. Je ne vais pas répéter ce qui a déjà été dit, que vous pouvez lire ici pourquoi.

Et n'oubliez pas qu'une fois que vous souhaitez déployer dans le GAC, votre installateur vous besoin des privilèges d'administrateur, vous pouvez très bien oublier de cliquer-une fois le déploiement, etc...

Answer 2

Utile en cas de GAC:

• COM-callable code - c'est à dire que vous en voulez non-.NET code pour être en mesure d'accéder à vous sans vous embêter avec dll etc
• Les Composants de service (COM+)
• Si vous écrivez du code qui est si commun, il est en fait un sens à l'utilisation du GAC - principalement .NET framework de composants etc
• Si vous souhaitez utiliser NGEN à pré-JIT le code

Autre que cela, j'ai tendance à éviter le GAC comme de la peste. Il est beaucoup plus facile de déployer le nécessaire avec dll de votre application via robocopy etc; ce qui donne l'isolement et la facilité de déploiement.

Answer 3

Si vous installez asp.net les applications web et que vous en êtes propriétaire et avez le contrôle complet de la machine, puis, dans certains cas, il peut être pertinent de mettre vos assemblées, à laquelle vous prévoyez de partager à travers les sites web des instances dans le global assembly cache.

Vous pourrait considérablement améliorer le temps de chargement initial et de l'utilisation de la mémoire de l'application sur les serveurs qui ont beaucoup de plusieurs instances de la même ASP.NET applications si vous mettez les assemblées dans le GAC. Au moins j'ai vu cela sur nos serveurs avec des dizaines d'installations.

Answer 4

Si vous expédiez une bibliothèque réutilisable composé de plusieurs assemblées, mais seulement quelques-uns d'entre eux forment une façade, vous pouvez envisager l'installation de l'assembly dans le GAC, si le paquet est installé à du développeur de les Ordinateurs.

Imaginez, vous expédiez 6 assemblées, et seulement l'un de ces 6 assemblées contient une façade - c'est à dire 5 autres sont uniquement utilisés par la façade elle-même. Vous navire:

• MyProduct.Facade.dll - c'est le seul composant destiné à être utilisé par les développeurs
• MyProduct.Core.dll - utilisé par MyProduct.Facade.dll mais pas destiné à être utilisé par les développeurs
• MyProduct.Component1.dll - le même
• MyProduct.Component2.dll - le même
• ThirdParty.Lib1.dll - la troisième partie de la bibliothèque utilisée par MyProduct.Component1.dll
• ThirdParty.Lib2.dll - le même
• etc.

Les développeurs à l'aide de votre projet voudrais juste une référence MyProduct.Facade.dll dans leurs propres projets. Mais lorsque leur projet est exécuté, il doit être en mesure de charger tous les assemblys référencés récursivement. Comment cela peut être réalisé? En général, ils doivent être offerts dans le dossier Bin, dans le GAC:

• Vous pouvez demander aux développeurs pour localiser votre dossier d'installation et d' ajouter des références à toutes les assemblées de vous y mettre. Cela permettra d'assurer qu'ils vont être copiés dans le dossier Bin pour être disponible au moment de l'exécution.
• Vous pouvez installer VS.NET modèle de projet contenant déjà ces 6 références. Un peu complexe, car il faudrait injecter le chemin de votre assemblées dans ce modèle avant son installation. Cela peut être fait seulement par l'installateur, car ce chemin dépend du chemin d'installation.
• Vous pouvez demander aux développeurs de créer un post spécial-étape de génération en .csproj / .fichier vbproj copier les dépendances nécessaires à dossier Bin. Les mêmes inconvénients.
• Enfin, vous pouvez installer tous vos assemblages dans le GAC. Dans ce cas, les développeurs doivent ajouter la référence juste pour MyProduct.Facade.dll de leur projet. Tout le reste sera disponible lors de l'exécution de toute façon.

Remarque: la dernière option permet de ne pas vous faire de faire de même lors de la livraison du projet à la production de Pc. Vous pouvez expédier toutes les assemblées au sein Bin, ou de les installer dans le GAC - tout dépend de votre souhait.

Donc, la solution décrite montre l'avantage de placer tiers des assemblages dans le GAC au cours du développement. Il n'a pas liées à la production.

Comme vous pouvez le trouver, l'installation dans le GAC est principalement destiné à résoudre le problème de l'emplacement des assemblys requis (dépendances). Si une assemblée est installé dans le GAC, vous pouvez considérer qu'il existe "à proximité" n'importe quelle application. C'est comme l'ajout de chemin .exe sur votre variable PATH, mais dans "géré de manière". - bien sûr, c'est plutôt une description simplifiée ;)

Answer 5

Voici le lien de Chris Vend appelé "Éviter le GAC"

http://www.sellsbrothers.com/spout/default.aspx?content=archive.htm#Avoid_the_GAC

L'explication est assez long, mais en bref, les deux cas il identifie

1. La fixation des bogues critiques sans toucher les applications concernées (et sans rien casser!)

2. Le partage de types à l'exécution, entre les assemblées déployés séparément

Remarque: Il y a un très long fil de discussion à la fin de Chris le post, très belle liste de commentaires.