متى ومتى لا يتم التثبيت في GAC؟

Question

متى يجب عليك التثبيت في GAC ومتى لا يجب عليك؟ (أنا أشير ، حقًا ، إلى التثبيت على جهاز العميل عندما يقومون بشراء منتجاتنا (S)).

1. لديّ مجموعة سيتم استخدامها فقط مع طلبي الواحد (GAC أو NO-GAC)؟

2. لديّ مجموعة تشاركها جميع تطبيقاتي (GAC أو NO-GAC)؟

3. كل تطبيقاتي مايو استخدم إصدارات مختلفة من التجميع (GAC أو NO-GAC)؟

هذه ثلاثة سيناريوهات ... لكنني متأكد من أن هناك المزيد. أنا لا أبحث بالضرورة إجابة على هذه الأسئلة الثلاثة فقط.

سؤال مماثل: ما هي مزايا وعيوب استخدام GAC؟

Answer 1

إرشادات MS العامة

1. رقم
2. رقم
3. رقم

GAC هو حقا مستودع لمكتبات Microsoft Common .NET. نعم ، يسمحون للمطورين باستخدامه أيضًا ، ولكن كقاعدة عامة ، إذا لم تكن بحاجة إلى GAC ، فلا تستخدمه. حافظ على الأمور بسيطة ومحلية إذا لم تؤلمني.

• سأفكر في GAC فقط لأسباب الأداء ، على سبيل المثال إذا كان لديك بعض التجميعات الضخمة ، حاول وضعها في GAC و Ngen هم. يجب أن تزيد بشكل كبير من الأداء. تقوم Microsoft بذلك لجميع تجميعات إطار العمل القياسية .NET أثناء التثبيت (أنت تعرف الآن لماذا يستغرق هذا التثبيت وقتًا طويلاً). Paint.net يفعل ذلك أيضًا (لتحسين وقت بدء تشغيل التطبيق). ومع ذلك ، لا يعمل معظمنا على أطراف ضخمة أو منافسي Photoshop ، لذلك في معظم الوقت ، فإن المكاسب الأداء من الحصول على التجميع في GAC ضئيلة. لا يستحق التخلي عن نشر XOPY البسيط.

• قد يستخدم بعض المطورين GAC للتأكد من أن المستخدمين الذين لديهم امتيازات غير كافية لا يمكنهم حذف أو تعديل مجموعاتهم.

• بالنسبة للآخرين ، قد يكون ذلك لأسباب الإصدار ولكن هنا يجب أن تعيد النظر حقًا. لن أكرر ما قيل بالفعل ، يمكنك أن تقرأ هنا لماذا.

ولا تنسى أنه بمجرد أن ترغب في النشر في GAC ، سيحتاج المثبت الخاص بك إلى امتيازات المسؤول ، يمكنك نسيان نشر النقر إلى حد كبير ، إلخ ...

Answer 2

حالات مفيدة لـ GAC:

• رمز com-collable-أي أنك تريد أن تتمكن بعض الكود غير المتوحش من الوصول إليك دون العبث مع DLLs وما إلى ذلك
• المكونات المخدومة (com+)
• إذا كنت تكتب رمزًا شائعًا جدًا ، فمن المستحق في الواقع استخدام GAC - في المقام الأول .NET Framework Components وما إلى ذلك
• إذا كنت تريد استخدام Ngen لتولي الرمز المسبق

بخلاف ذلك ، أميل إلى تجنب GAC مثل الطاعون. من الأسهل بكثير نشر DLLs اللازمة مع تطبيقك عبر robocopy إلخ؛ هذا يعطي العزلة و سهولة النشر.

Answer 3

إذا كنت تقوم بتثبيت تطبيقات الويب ASP.NET وأنت المالك ولديك تحكم كامل في الجهاز ، ثم في بعض الحالات قد يكون من المنطقي وضع التجميعات الخاصة بك ، والتي تخطط لها شارك عبر المواقع/مثيلات الويب في ذاكرة التخزين المؤقت للتجميع العالمي.

يمكنك تحسين وقت التحميل الأولي واستخدام الذاكرة للتطبيق على الخوادم التي تحتوي على العديد من الحالات المتعددة من تطبيقات ASP.NET نفسها إذا وضعت التجميعات في GAC. على الأقل رأيت هذا على خوادمنا مع العشرات من المنشآت.

Answer 4

إذا كنت تقوم بشحن مكتبة قابلة لإعادة الاستخدام تتكون من مجموعات متعددة ، ولكن قلة منها فقط تشكل واجهة ، يمكنك التفكير في تثبيت التجميعات في GAC ، إذا تم تثبيت الحزمة على أجهزة الكمبيوتر الخاصة بالمطور.

تخيل أنك تشحن 6 تجمعات ، ولا تحتوي سوى واحدة من هذه التجميعات الستة على واجهة - أي 5 الأخرى يتم استخدامها فقط من خلال الواجهة نفسها. تشحن:

• myProduct.facade.dll - هذا هو المكون الوحيد الذي يقصد استخدامه من قبل المطورين
• myproduct.core.dll - يستخدمه myproduct.facade.dll ، ولكن لا يُقصد استخدامه من قبل المطورين
• myProduct.component1.dll - نفس الشيء
• myProduct.component2.dll - نفس الشيء
• Thirdparty.lib1.dll - مكتبة طرف ثالث تستخدمها MyProduct.component1.dll
• Thirdparty.lib2.dll - نفس الشيء
• إلخ.

يود المطورون الذين يستخدمون مشروعك الإشارة فقط myProduct.facade.dll في مشاريعهم الخاصة. ولكن عند تشغيل مشروعهم ، يجب أن يكون قادرًا على تحميل جميع التجميعات التي تشير إليها - بشكل متكرر. كيف يمكن تحقيق ذلك؟ بشكل عام ، يجب أن تكون متوفرة إما في مجلد بن ، في GAC:

• قد تطلب من المطورين تحديد موقع مجلد التثبيت و أضف مراجع إلى جميع n التجميعات التي وضعتها هناك. سيضمن ذلك أن يتم نسخهم إلى مجلد Bin ليكونوا متاحين في وقت التشغيل.
• يمكنك تثبيت قالب مشروع VS.NET تحتوي بالفعل على هذه المراجع الستة. معقدة بعض الشيء ، لأنه يجب عليك حقن المسار الفعلي لتجميعاتك في هذا القالب قبل التثبيت. لا يمكن القيام بذلك إلا عن طريق المثبت ، لأن هذا المسار يعتمد على مسار التثبيت.
• قد تطلب من المطورين إنشاء خطوة خاصة بعد البناء في ملف .csproj / .vbproj نسخ التبعيات اللازمة إلى مجلد بن. نفس العيوب.
• أخيرًا ، قد تثبيت جميع تجميعاتك في GAC. في هذه الحالة ، يجب على المطورين إضافة الإشارة فقط إلى myproduct.facade.dll من مشروعهم. كل شيء آخر سيكون متاحًا في وقت التشغيل على أي حال.

ملاحظة: الخيار الأخير لا يجعلك تفعل الشيء نفسه أثناء شحن المشروع إلى أجهزة الكمبيوتر الإنتاجية. يمكنك إما شحن جميع التجميعات داخل مجلد Bin ، أو تثبيتها في GAC - كل ما يعتمد على كل أمنيتك.

لذلك يوضح الحل الموصوف ميزة وضع تجمعات الطرف الثالث في GAC أثناء التطوير. لا يرتبط بالإنتاج.

كما قد تجد ، يهدف التثبيت في GAC بشكل أساسي إلى حل مشكلة موقع التجميعات المطلوبة (التبعيات). إذا تم تثبيت التجميع في GAC ، فقد تعتبره موجودًا "بالقرب من" أي تطبيق. إنه مثل إضافة المسار إلى .exe إلى متغير المسار الخاص بك ، ولكن في "الطريق المدارة". - بالطبع ، هذا وصف مبسط إلى حد ما ؛)

Answer 5

إليك الرابط من كريس يسمى "تجنب GAC"

https://sellsbrothers.com/12503

التفسير طويل جدًا ، لكن باختصار ، الحالتين الذي يحدده

1. إصلاح الأخطاء الحرجة دون لمس التطبيقات المتأثرة (ودون كسر أي شيء!)

2. مشاركة الأنواع في وقت التشغيل بين التجميعات المنتشرة بشكل منفصل

ملاحظة: هناك موضوع نقاش طويل جدًا في نهاية كريس بوست, ، قائمة جميلة جدا من التعليقات.

Answer 6

أولاً ، إذا كنت تقوم بتثبيت هذا على جهاز عميل ، فستحتاج إلى إضافة إجراء مخصص لتثبيت التطبيق في GAC وآخر عند الإزالة.

في القضية بالتأكيد ليس gac

في الحالة B إذا كانت مكتبتك تتغير باستمرار ، فستحتاج إلى إضافة كل إصدار من التجميع إلى GAC في كل مرة ويحدث هذا التجميع

في الحالة C ، يتيح لك التنفيذ جنبًا إلى جنب تشغيل إصدارات تجميع مختلفة ولا تحتاج إلى إضافة أي شيء لتمييز الإصدارات.

تستخدم فقط إذا كنت بحاجة حقًا

Answer 7

من المنطقي فقط التثبيت في GAC إذا كانت الكثير والكثير من تطبيقات الويب على نفس الخادم ستشارك في نفس المكتبات بالضبط. على سبيل المثال ، على خادم SharePoint ، يمكن أن يكون هناك المئات من مواقع الويب التي تحتاج جميعًا إلى مشاركة جزء الويب نفسه ، لذلك في هذه الحالة ، من المنطقي نشر جزء الويب المترجم إلى GAC.