Quand dois-je déployer mes assemblys dans le GAC?

Je voudrais savoir pratiquement quel genre d’assemblées dois-je déployer dans GAC.

Cas 1 : Si dans ma solution, plusieurs projets utilisent log4net.dll, devraient-ils être déployés dans GAC?

Cas 2 : Si plusieurs applications sont déployées sur un ordinateur, chacune utilisant log4net.dll est-ce la raison suffisante pour déployer log4net.dll dans GAC?

Question: Quand dois-je déployer mes assemblys dans le GAC?

Réponse: jamais

Réel, honnête, réel Réponse: à peine jamais

Discussion

Ne déposez les éléments dans le GAC que lorsque plusieurs applications sur la machine utiliseront l’assembly et lorsque l’assembly est fondamental (susceptible d’être utilisé par plusieurs applications), lorsqu’il est signé et que vous ne prévoyez presque jamais de mettre à jour cet assembly. Peut-être append à cela, quand avoir plusieurs versions indépendantes d’une DLL déployée avec chaque application serait réellement dangereux.

Un exemple de ces derniers est: supposons que vous ayez 2 applications indépendantes, développées indépendamment et déployées de manière indépendante. Néanmoins, il est possible qu’ils communiquent entre eux. Ils vont échanger … quelque chose … sur .NET Remoting sur la machine locale. Si vous avez un seul assemblage dans le GAC, ces applications sont assurées que l’intercommunication fonctionnera. Si, cependant, ils ont chacun une version distincte d’un assemblage, ils ne pourront peut-être pas échanger d’objects. Ceci est si rare que vous n’en avez probablement pas besoin. Si vous n’êtes pas sûr, alors vous n’en avez pas besoin.


Le scénario GAC de base est la bibliothèque de classes de base .NET. Ces assemblages sont livrés par Microsoft. Ils font autorité. Ils sont fondamentaux. et signé. Ils changent rarement. Toutes les applications doivent utiliser les mêmes copies de ces DLL. Par conséquent, ils appartiennent au GAC.

En revanche, vos DLL d’application ne proviennent pas de Microsoft, elles ne sont pas essentielles et ne sont probablement pas signées. Ils changent plus souvent et il n’y a que peu d’applications (peut-être une seule!) Qui utilisent chaque DLL. Pas de GAC.


Je pourrais imaginer un périphérique matériel, disons un appareil photo numérique, qui installe un assemblage .NET pour permettre la programmabilité. C’est un scénario où l’assemblage pourrait bien s’intégrer dans le GAC. Il permet aux applications .NET arbitraires d’accéder à l’appareil photo numérique par programmation.


Votre exemple de log4net n’est pas, à mon avis, suffisant pour justifier le assembly de l’assemblage dans le GAC. Imaginez le scénario où l’une des applications reçoit une mise à jour et, dans le cadre de la mise à jour, utilise une nouvelle version de log4net. Maintenant quoi? Le nouvel ensemble log4net doit-il être placé dans le GAC? Probablement pas.

L’idée de partager des DLL entre plusieurs applications était liée au fait que la mémoire et le stockage sur disque étaient rares. Il était une fois, c’était vrai. Ce n’est plus vrai, plus longtemps. En cas de doute, n’utilisez pas le GAC.

log4net.dll a une taille de 95 Ko. Même si vous le déployez 100 fois, cela n’aurait pas vraiment d’importance avec les disques durs d’aujourd’hui. J’essaie d’éviter le GAC dans la mesure du possible pour plusieurs raisons:

  • cela rend le déploiement plus difficile, vous devez dire à l’installateur ce qu’il faut mettre dans le GAC. J’aime la possibilité de créer de simples configurations xcopy (copiez un répertoire pour l’installer, supprimez-le pour le désinstaller). parce que c’est simple – mais ça ne marche pas si vite que vous devez mettre les choses dans le GAC.
  • vous devez signer vos assemblées. seulement pour les faire entrer dans le GAC ….
  • dès qu’un développeur référence quelque chose du GAC dans son projet de studio visuel, la référence sera perdue lorsqu’un autre développeur ouvre la solution sur son PC. il devra d’abord obtenir les assemblages requirejs dans le GAC avant de pouvoir ouvrir et comstackr avec succès la solution. c’est un vrai PITA. Je veux pouvoir vérifier, comstackr et exécuter sans erreurs.

Le seul type d’assemblage que vous devriez envisager de mettre en place dans le GAC est un assemblage mature et stable. Dans le cas de log4net, si vous êtes satisfait de la stabilité de la version que vous possédez, et que vous n’êtes pas susceptible de changer cette version de sitôt, n’hésitez pas à la mettre dans le GAC.

N’essayez pas de placer des bibliothèques dans le GAC susceptibles de changer, surtout si vous les développez en interne et que des améliorations sont encore possibles. Déployez-les en tant qu’assemblées privées à la place.

J’ai vu des gens évangéliser l’émerveillement du code partagé. Ils disent des choses comme “ah, nous allons améliorer 20 applications en même temps avec ce changement de code”. Le problème est que vous pouvez également détruire 20 applications en même temps si vous vous trompez. J’ai vu des gens dire “Je viens de lancer le site X. Pouvez-vous s’il vous plaît vérifier les sites AW pour vous assurer qu’ils fonctionnent toujours?”.

Les assemblys privés peuvent être pénibles, mais les problèmes que vous pouvez rencontrer sont limités à l’application spécifique sur laquelle ils sont déployés. Si vous n’êtes pas sûr à 100% qu’un assemblage n’est pas stable et mature, ne le mettez pas dans le GAC.

Croyez-moi, vous dormirez mieux.

Ce que vous décrivez est une situation suffisamment décente pour placer un assemblage dans le GAC. En vérité, je l’éviterais bien. Avec le GAC, vous devez vous soucier des assemblages de noms et de confiance et du contrôle de version des assemblages. Si vous n’avez pas de raison explicite pour en avoir besoin. Il est tout aussi facile de déployer le dll plusieurs fois pour chaque projet.

Je sais que cela va à l’encontre du stockage de plusieurs copies du même morceau de code, etc., etc., mais j’ai toujours trouvé qu’il était plus simple d’éviter l’utilisation du GAC. Lorsque je l’ai utilisé, le GAC a toujours été gênant, car vous devez vous inquiéter si le GAC dispose de tous les assemblages corrects pour le projet (car les assemblys peuvent référencer d’autres assemblages). Lorsque vous n’utilisez pas le GAC, il est beaucoup plus facile d’y aller, “Les assemblages sont-ils là?” “Ouais, ils sont dans le dossier de l’application.”

La seule fois où je l’ai trouvé utile, c’est quand j’ai dû créer un SharePoint Services WSS 2.0. Je me suis retrouvé à une époque où la mise à jour de la section de configuration pour permettre la confiance était lourde (à cause de la politique d’entreprise) et le placer dans le GAC pour lui permettre d’être totalement fiable ne l’était pas. C’était un cas très rare.