هل هناك أسباب وجيهة للترك تجميع المباراة والتجميع؟

Question

Gendarme لديه AvoidAssemblyVersionMismatchRule مع الوصف التالي:

تتحقق هذه القاعدة من أن [AssemblyVersion] يطابق [AssemblyFileVersion] عندما يكون كلاهما موجودين داخل التجميع. يمكن أن يكون وجود أرقام إصدار مختلفة في كلتا السمة مربكًا بمجرد نشر التطبيق.

على سبيل المثال ، ستحذر هذه القاعدة من Microsoft's System.dll التي لديها السمات التالية:

[assembly: AssemblyVersion("2.0.0.0")]
[assembly: AssemblyFileVersion("2.0.50727.3053")]

أنا لا أوافق على حكم جيندرم. متابعته سيجعل من المستحيل استخدام نظام الإصدار المشابه للنظام الذي يستخدمه Microsoft ، أي

• تحديث AssemblyFileVersion على كل بناء ،
• يتغيرون AssemblyVersion فقط على الواجهة العامة أو التغييرات الرئيسية بطريقة أخرى ،
• تأكد من أن AssemblyVersion و AssemblyFileVersion مشاركة بادئة مشتركة ،

وأعتقد أن مخطط الإصدار هذا هو سبب التصميم الذي أصبح ممكنًا للتمييز بين AssemblyVersion و AssemblyFileVersion في المقام الأول.

لا يمكنني التوصل إلى سبب يجعل فرض كل من سمات التجميع على قدم المساواة هو ممارسة جيدة ، ولكن ربما يمكنك ذلك! سأكون مهتمًا بآرائك.

إذا لم يكن هناك بالفعل سبب وجيه ، فسأقترح قريبًا على مطوري Gendarme تغيير القاعدة إلى

تتحقق هذه القاعدة من أن [AssemblyVersion] و [AssemblyFileVersion] لديك بادئة مشتركة غير فارغة عندما يكون كلاهما موجودين داخل التجميع.

Answer 1

أوافق ، إذا كان ينبغي أن يتطابقوا ، فلن يكون هناك ما يجب أن يكون هناك سمتان مختلفتان لتبدأ! ولكن كما تقول القاعدة: يمكن أن تكون مربكة.

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

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

Answer 2

وافق ، هذه قاعدة سخيفة. لا يمكنك نشر تحديث لإصلاح الأخطاء المتساقط لتجميع مسمى قوي عند متابعته. هناك أسباب قليلة لعدم جعلها نفس الشيء إذا كان عليك بالفعل تغيير [AssemblyVersion]. ربما ليس من المفترض أن تستخدم هذه الأداة عند إصلاح الأخطاء. ساخر.

Answer 3

أعتقد أن القاعدة منطقية في العديد من السيناريوهات ، نظرًا لأن إطار .NET يعتبر أساسًا تجمعين مع نفس التجميع ليكون قابلاً للتبديل.

لذلك ، على سبيل المثال ، لن يتم كتابة إصدار قديم في ذاكرة التخزين المؤقت للتنزيل تلقائيًا بواسطة إصدار جديد يختلف فقط في AssemblyFileversion.

هذا يمكن أن يكون مربكا للمطور العادي ، وبالتالي القاعدة.

بالطبع ، إذا كنت تعرف ما تفعله وفهمت المقايضات ، فيمكنك تجاهل القاعدة.