سؤال

ما الذي يعتبر أفضل ممارسة عندما يتعلق الأمر بالتجميعات والإصدارات؟

أود أن أكون قادرًا على الرجوع إلى إصدارات متعددة من نفس المكتبة - يحتوي الحل على مشاريع متعددة تعتمد على إصدارات مختلفة من مكتبة commonutils.dll التي نبنيها بأنفسنا.

نظرًا لأنه يتم نسخ كافة التبعيات إلى bin/debug أو bin/release، يمكن أن توجد نسخة واحدة فقط من commonutils.dll هناك على الرغم من أن كل ملف من ملفات DLL له أرقام إصدار تجميع مختلفة.

هل يجب علي تضمين أرقام الإصدارات في اسم التجميع حتى أتمكن من الرجوع إلى إصدارات متعددة من المكتبة أم أن هناك طريقة أخرى؟

هل كانت مفيدة؟

المحلول

هذا ما كنت أعيش به --

يعتمد ذلك على ما تخطط لاستخدام ملفات DLL من أجله.أقوم بتصنيفهم إلى مجموعتين رئيسيتين:

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

  2. الجمعيات المشار إليها.قم بتسميتها بشكل واضح حتى تتمكن من الحصول على إصدارات متعددة منها يتم الرجوع إليها بواسطة التجميعات الأخرى.استخدم الاسم الكامل للإشارة إليها (Assembly.Load).احتفظ بنسخة من أحدث وأروع إصدار منه في مكان يمكن أن تشير إليه تعليمات برمجية أخرى.

بعد ذلك، لديك خيار نسخ مراجعك المحلية أم لا.في الأساس، تتلخص المقايضة في - هل تريد الحصول على تصحيحات/ترقيات من مراجعك؟يمكن أن تكون هناك قيمة إيجابية في ذلك من الحصول على وظائف جديدة، ولكن من ناحية أخرى، قد تكون هناك تغييرات عاجلة.أعتقد أن القرار هنا يجب أن يتم اتخاذه على أساس كل حالة على حدة.

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

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

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

بمجرد الوصول إلى وقت التشغيل، يمكنك التجميع. قم بتحميل ما تريد في الملف مجال التطبيق.وبعد ذلك، يمكنك استخدام Assembly.GetType للوصول إلى النوع الذي تريده.إذا كان لديك نوع موجود في تجميعات متعددة محملة (كما هو الحال في إصدارات متعددة من نفس المشروع)، فقد تحصل على AmbigiousMatchException استثناء.لحل هذه المشكلة، ستحتاج إلى الحصول على النوع من مثيل متغير التجميع، وليس أسلوب Assembly.GetType الثابت.

نصائح أخرى

يمكن أن تتواجد التجميعات في GAC (ذاكرة التخزين المؤقت للتجميع العمومي) حتى لو كانت تحمل نفس الاسم نظرًا لاختلاف الإصدار.هذه هي الطريقة التي تعمل بها التجميعات التي يتم شحنها بواسطة .NET Framework.أحد المتطلبات التي يجب استيفاؤها حتى يتمكن التجمع من التسجيل في GAC هو التوقيع.

إن إضافة أرقام الإصدارات إلى اسم التجميع يؤدي إلى هزيمة الغرض الكامل من نظام التجميع البيئي وهو أمر مرهق IMHO.لمعرفة إصدار التجميع المحدد، قمت فقط بفتح نافذة الخصائص والتحقق من الإصدار.

إن إعطاء أسماء مختلفة لإصدارات التجميع المختلفة هي الطريقة الأسهل وهي ناجحة بالتأكيد.

إذا كان التجميع الخاص بك (commonutils.dll) ذو اسم قوي (أي.موقع)، يمكنك التفكير في تثبيته في GAC (ذاكرة التخزين المؤقت للتجميع العمومي - يمكنك تثبيت إصدارات مختلفة من نفس التجميع جنبًا إلى جنب في GAC)، وبالتالي يحصل تطبيق الاتصال تلقائيًا على الإصدار المناسب من هناك لأن .NET تتضمن الأنواع معلومات إصدار التجميع.

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

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top