J'aimerais savoir pratiquement quel type d'assemblées devrais-je déployer au sein de GAC.
Cas 1 : Si dans ma solution plusieurs projets utilisent log4net.dll, doit-il être déployé dans GAC?
Cas 2 : Si plusieurs applications sont déployées sur une machine, chacune utilisant log4net.dll, est-ce une raison suffisante pour déployer log4net.dll dans le GAC?
Question: Quand dois-je déployer mon assembly dans le GAC?
Réponse: Jamais
Réel, honnête, Vraie Réponse: presque Jamais
Discussion
Seulement la chute des choses dans le GAC lorsque plusieurs applications sur la machine utilisera l'assemblée, et lorsque l'assemblée est à la base (susceptible d'être utilisé par plusieurs applications), quand il est signé, et quand vous comptez presque jamais de mise à jour de cette assemblée. Peut-être ajouter que, lorsque le fait d'avoir plusieurs versions indépendantes d'une DLL déployé avec chaque application pourrait être dommageable.
Un exemple de ce dernier est: supposons que vous avez 2 applications indépendantes, indépendamment développé et déployé indépendamment. Néanmoins, il y a un possibbility qu'ils vont communiquer entre eux. Ils vont échanger ... quelque chose... de plus .NET Remoting sur la machine locale. Si vous avez un seul assembly dans le GAC, ces applications sont assurés que l'inter-communication tout fonctionne. Si, toutefois, ils ont chacun une version distincte de l'assemblée, ils peuvent ne pas être en mesure d'échanger des objets. C'est un événement rare que vous n'avez probablement pas besoin. Si vous n'êtes pas sûr, alors vous n'en avez pas besoin.
La base GAC scénario est le .NET de la Bibliothèque de classes de Base. Ces assemblées sont fournis par Microsoft. Ils font foi. 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 à la GAC.
En revanche, votre demande de Dll sont pas de Microsoft, ils ne sont pas fondamentales, et probablement pas signé. Ils changent plus souvent, et il y a seulement quelques applications (peut-être un seul!) qui DLL. Pas de GAC.
Je ne pouvais imaginer un périphérique matériel, disons un appareil photo numérique, qui installe une .NET de l'assemblée pour permettre la programmabilité. C'est un scénario où l'assemblée pourrait bien s'insérer dans le GAC. Il permet à l'arbitraire .NET applications pour accéder à l'appareil photo numérique par programmation.
Votre log4net exemple n'est pas, à mon avis, suffisant pour justifier la mise en service de l'assembly dans le GAC. Imaginez un scénario où l'une des applications obtient une mise à jour, et dans le cadre de la mise à jour, il utilise une nouvelle version de log4net. Maintenant ce qui? Si le nouveau log4net assemblée être placé dans le GAC? Probablement pas.
L'idée de partager Dll à travers les applications, était fondée sur la prémisse que la mémoire et le stockage des disques rares. Une fois, que c'était vrai. Il n'est pas vrai, plus longtemps. En cas de doute, n'utilisez pas le GAC.
l'log4net.dll a une taille de 95KB. même si vous déployez un 100 fois il n'a 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:
Le seul genre de montage que vous devriez envisager de mettre dans le GAC est mature et stable de l'assemblée. Dans le cas de log4net, si vous êtes heureux que la version que vous avez est stable, mature et vous n'êtes pas susceptible de changer la version de sitôt, n'hésitez pas à le mettre dans le GAC.
Ne tentez pas de la place des bibliothèques dans le GAC qui sont susceptibles de changer, surtout si vous êtes en développement en interne et il y a encore place à l'amélioration. De les déployer en tant que privé, assemblées à la place.
J'ai vu des gens évangéliser la merveille de code partagé. Ils disent des choses comme "ah, nous allons améliorer les 20 applications en même temps avec ce changement de code". Le problème est, vous pouvez aussi détruire les 20 applications en même temps si vous vous trompez. J'ai vu des gens dire "j'ai juste lancé le site X. Pouvez-vous s'il vous plaît vérifier les sites A-W pour s'assurer qu'ils fonctionnent encore?".
Privé assemblées peut être une douleur, mais les problèmes que vous pourriez faire face sont limitées à l'application spécifique qu'ils sont déployés contre. Si vous n'êtes pas sûr à 100% que l'assemblée n'est pas stable et mature, ne pas le mettre dans le GAC.
Faites-moi confiance, vous dormirez mieux.
Ce que vous décrivez est assez décent de la situation pour mettre un assembly dans le GAC. Honnêtement, je voudrais éviter si. Avec le GAC, vous avez à vous soucier fort de nommage et de faire confiance à des assemblées et de l'assemblage spécifique de contrôle de version. Si vous n'avez pas un but explicite de besoin. Il est tout aussi facile à déployer de la dll à plusieurs reprises pour chaque projet.
Je sais que cela va à l'encontre de stocker plusieurs copies d'un même morceau de code etc. etc., mais j'ai toujours trouvé ça plus facile que d'éviter d'utiliser le GAC. Lorsque je l'ai utilisé, le GAC a toujours été source de problèmes, parce que vous avez à vous inquiéter si le GAC a toutes les assemblées du projet (parce que les assemblées peuvent faire référence à d'autres assemblées). Lorsque vous n'utilisez pas le cas, il est beaucoup plus facile d'aller, "Sont assemblées là?" "Ouais ils sont dans le dossier de l'application."
La seule fois où je l'ai trouvé utile a été lorsque j'ai eu à construire un SharePoint Services WSS 2.0. J'ai couru dans un moment où la mise à jour de la section de configuration pour permettre à la confiance lourde (en raison de la politique de l'entreprise) et de le placer dans le GAC pour lui permettre d'être pleinement confiance ne l'était pas. C'est un cas très rare.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
