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

Question

يتوفر في .NET رقمان للإصدار عند إنشاء مشروع، إصدار الملف وإصدار التجميع.كيف تستخدم هذه الأرقام؟إبقاءهم على حالهم؟هل تريد زيادة أحدهما تلقائيًا، ولكن تغيير الآخر يدويًا؟

وماذا عن AssemblyInformationalVersion يصف؟

لقد عثرت على مقالة دعم قاعدة معارف Microsoft (KB) التي قدمت بعض المساعدة: كيفية استخدام إصدار التجميع وإصدار ملف التجميع.

Answer 1

في سيناريو حيث لدي تجميعات ملفات متعددة (أي.1 exe و5 ملفات dll) سأستخدم إصدار ملف مختلفًا لكل منها، ولكن نفس إصدار التجميع لكل منها، مما يسمح لك بمعرفة ملف exe الذي يتوافق مع كل ملف من ملفات dll.

Answer 2

في الحلول التي تحتوي على مشاريع متعددة، هناك شيء واحد وجدته مفيدًا للغاية وهو أن جميع ملفات AssemblyInfo تشير إلى مشروع واحد يتحكم في الإصدار.لذا فإن AssemblyInfos الخاص بي يحتوي على سطر:

[assembly: AssemblyVersion(Foo.StaticVersion.Bar)]

لدي مشروع يحتوي على ملف واحد يعلن عن السلسلة:

namespace Foo
{
    public static class StaticVersion
    {
         public const string Bar= "3.0.216.0"; // 08/01/2008 17:28:35
    }
}

تقوم عملية الإنشاء التلقائية بعد ذلك بتغيير تلك السلسلة عن طريق سحب أحدث إصدار من قاعدة البيانات وزيادة الرقم الأخير الثاني.

أقوم فقط بتغيير رقم الإصدار الرئيسي عندما تتغير مجموعة الميزات بشكل كبير.

لا أقوم بتغيير إصدار الملف على الإطلاق.

Answer 3

تشير مقالة KB إلى التمييز الأكثر أهمية:يتم استخدام إصدارات الملفات فقط لأغراض العرض، بينما يلعب إصدار التجميع دورًا مهمًا في سلوك تحميل .NET.

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

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

Answer 4

يتم استخدام إصدارات الملفات فقط لأغراض العرض، بينما يلعب إصدار التجميع دورًا مهمًا في سلوك تحميل .NET.

ليس تماما.يعد إصدار الملف مهمًا أيضًا لبرنامج Windows Installer عند ترقية إصدار موجود عبر إصدار سابق.

Answer 5

في تطبيقي الحالي، يحتوي كل مشروع VS على رابط إلى ملف المصدر "AssemblyBuildInfo" الذي يحتوي على السمات التالية:

[assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyCompany("Acme Corporationy")]
[assembly: AssemblyCopyright("Copyright ©  2009 Acme Corporation")]

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

Answer 6

@آدم:هل تقوم بتغيير إصدار الملف مع كل بناء؟هل تستخدم التحكم في الإصدار (SYN أو VSS) وتستخدم هذه المعلومات لربط المصدر مرة أخرى بالثنائيات؟

يبدو من المنطقي أن يبقى إصدار التجميع كما هو.أي."2.0.0.0".وهذا يتوافق مع نشر المنتج.

يتغير إصدار الملف ليطابق المراجعة من التحكم بالمصدر."2.0.؟؟.revision" هذا من شأنه أن يوفر رابطًا من ملف dll (أو exe) محدد إلى المصدر الذي قام بإنشائه.

Answer 7

لقد كتبت تدوينة حول هذا الموضوع والتي قد تكون مفيدة للمجتمع http://blog.raffaeu.com/archive/2011/12/11/sharing-assembly-version-in-visual-studio-2010.aspx

Answer 8

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