ما هي الاختلافات بين AssemblyVersion وAssemblyFileVersion وAssemblyInformationalVersion؟
https://stackoverflow.com/questions/64602
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
هناك ثلاث سمات لإصدار التجميع.ما هي الاختلافات؟هل هو موافق إذا كنت تستخدم AssemblyVersion وتجاهل الباقي؟
يقول MSDN:
-
يحدد إصدار التجميع المنسوب.
-
يرشد المترجم لاستخدام رقم إصدار محدد لمورد إصدار الملف Win32.ليس من الضروري أن يكون إصدار الملف Win32 هو نفس رقم إصدار التجميع.
-
يحدد معلومات الإصدار الإضافية لبيان التجميع.
هذه متابعة ل ما هي أفضل الممارسات لاستخدام سمات التجميع؟
المحلول
إصدار التجميع
حيث ستبدو التجميعات الأخرى التي تشير إلى التجميع الخاص بك.إذا تغير هذا الرقم، فيجب على التجميعات الأخرى تحديث مراجعها إلى التجميع الخاص بك!ال AssemblyVersion مطلوب.
أستخدم التنسيق: أساسي ثانوي.وهذا من شأنه أن يؤدي إلى:
[assembly: AssemblyVersion("1.0")]
AssemblyFileVersion
تستخدم للنشر.يمكنك زيادة هذا العدد لكل عملية نشر.يتم استخدامه من خلال برامج الإعداد.استخدمه لتمييز التجميعات التي لها نفس الشيء AssemblyVersion, ، ولكن يتم إنشاؤها من بنيات مختلفة.
في نظام التشغيل Windows، يمكن الاطلاع عليه في خصائص الملف.
إذا كان ذلك ممكنًا، دعه يتم إنشاؤه بواسطة MSBuild.يعد AssemblyFileVersion اختياريًا.إذا لم يتم تقديمه، فسيتم استخدام AssemblyVersion.
أستخدم التنسيق: Major.minor.revision.build, حيث أستخدم المراجعة لمرحلة التطوير (Alpha وBeta وRC وRTM) وحزم الخدمة والإصلاحات السريعة.وهذا من شأنه أن يؤدي إلى:
[assembly: AssemblyFileVersion("1.0.3100.1242")]
AssemblyInformationalVersion
إصدار المنتج للتجميع.هذا هو الإصدار الذي ستستخدمه عند التحدث إلى العملاء أو للعرض على موقع الويب الخاص بك.يمكن أن يكون هذا الإصدار عبارة عن سلسلة، مثل '1.0 الافراج عن المرشح'.
سوف يشكو تحليل الكود من ذلك (CA2243) - ذكرت لمايكروسوفت (غير ثابت في VS2013).
ال AssemblyInformationalVersion هو اختياري.إذا لم يتم تقديمه، فسيتم استخدام AssemblyFileVersion.
أستخدم التنسيق: Major.minor [المراجعة كسلسلة].وهذا من شأنه أن يؤدي إلى:
[assembly: AssemblyInformationalVersion("1.0 RC1")]
نصائح أخرى
يمكن أن يكون إصدار التجميعات في .NET احتمالًا مربكًا نظرًا لوجود ثلاث طرق على الأقل حاليًا لتحديد إصدار للتجميع الخاص بك.
فيما يلي سمات التجميع الرئيسية الثلاث المتعلقة بالإصدار:
// Assembly mscorlib, Version 2.0.0.0
[assembly: AssemblyFileVersion("2.0.50727.3521")]
[assembly: AssemblyInformationalVersion("2.0.50727.3521")]
[assembly: AssemblyVersion("2.0.0.0")]
وفقًا للاتفاقية، يُشار إلى الأجزاء الأربعة من الإصدار باسم النسخة الرئيسية, نسخة ثانوية, يبني, ، و مراجعة.
ال AssemblyFileVersion يهدف إلى التعرف بشكل فريد على بنية التجمع الفردي
عادةً ما ستقوم يدويًا بتعيين إصدار ملف التجميع الرئيسي والثانوي ليعكس إصدار التجميع، ثم قم بزيادة الإصدار و/أو المراجعة في كل مرة يقوم فيها نظام البناء الخاص بك بتجميع التجميع.يجب أن يسمح لك AssemblyFileVersion بتعريف بنية التجميع بشكل فريد، بحيث يمكنك استخدامها كنقطة بداية لتصحيح أي مشاكل.
في مشروعي الحالي، لدينا خادم البناء الذي يقوم بتشفير رقم قائمة التغيير من مستودع التحكم بالمصدر الخاص بنا إلى أجزاء البناء والمراجعة في AssemblyFileVersion.يتيح لنا هذا التعيين مباشرةً من التجميع إلى كود المصدر الخاص به، لأي تجميع تم إنشاؤه بواسطة خادم الإنشاء (دون الحاجة إلى استخدام التصنيفات أو الفروع في التحكم بالمصادر، أو الاحتفاظ بأي سجلات للإصدارات التي تم إصدارها يدويًا).
يتم تخزين رقم الإصدار هذا في مورد إصدار Win32 ويمكن رؤيته عند عرض صفحات خصائص Windows Explorer الخاصة بالتجميع.
لا يهتم CLR بـ AssemblyFileVersion ولا يفحصه.
ال AssemblyInformationalVersion يهدف إلى تمثيل إصدار المنتج بأكمله
يهدف AssemblyInformationalVersion إلى السماح بإصدار متماسك للمنتج بأكمله، والذي قد يتكون من العديد من التجميعات التي يتم إصدارها بشكل مستقل، ربما مع سياسات إصدار مختلفة، ومن المحتمل أن يتم تطويرها بواسطة فرق متباينة.
"على سبيل المثال ، قد يحتوي الإصدار 2.0 من المنتج على عدة مجموعات ؛يتم تمييز إحدى هذه التجميعات كإصدار 1.0 لأنها مجموعة جديدة لم تشحن في الإصدار 1.0 من نفس المنتج.عادةً ما تقوم بتعيين الأجزاء الرئيسية والثانوية من رقم الإصدار لتمثيل الإصدار العام لمنتجك.ثم تقوم بزيادة قطع غيار البناء والمراجعة في كل مرة تقوم فيها بتعبئة منتج كامل مع جميع مجموعاته. " - جيفري ريختر ، [CLR عبر C# (الطبعة الثانية)] ص.57
لا يهتم CLR بـ AssemblyInformationalVersion ولا يفحصه.
ال AssemblyVersion هو الإصدار الوحيد الذي يهتم به CLR (لكنه يهتم بالملف بأكمله AssemblyVersion)
يتم استخدام AssemblyVersion بواسطة CLR لربط التجميعات ذات الأسماء القوية.يتم تخزينه في جدول بيانات تعريف بيان AssemblyDef الخاص بالتجميع المبني، وفي جدول AssemblyRef لأي تجميع يشير إليه.
هذا مهم جدًا، لأنه يعني أنه عند الإشارة إلى تجميع مسمى بقوة، فإنك تكون مرتبطًا بشدة بإصدار تجميعي محدد لهذا التجميع.يجب أن يكون إصدار التجميع بالكامل متطابقًا تمامًا حتى ينجح الربط.على سبيل المثال، إذا قمت بالرجوع إلى الإصدار 1.0.0.0 من مجموعة ذات أسماء قوية في وقت الإنشاء، ولكن الإصدار 1.0.0.1 فقط من ذلك التجميع هو المتاح في وقت التشغيل، فسوف يفشل الربط!(سيتعين عليك بعد ذلك حل هذه المشكلة باستخدام إعادة توجيه ملزمة التجميع.)
الارتباك حول ما إذا كان كاملا AssemblyVersion يجب أن تتطابق.(نعم إنها كذلك.)
هناك بعض الالتباس حول ما إذا كان إصدار التجميع بالكامل يجب أن يكون متطابقًا تمامًا حتى يتم تحميل التجميع.يعتقد بعض الأشخاص خطأً أن الأجزاء الرئيسية والثانوية فقط من نسخة التجميع هي التي يجب أن تتطابق حتى ينجح الربط.يعد هذا افتراضًا معقولًا، ولكنه غير صحيح في النهاية (اعتبارًا من .NET 3.5)، ومن السهل التحقق من ذلك لإصدار CLR الخاص بك.فقط نفذ هذا الكود النموذجي.
فشل تحميل التجميع الثاني على جهازي، ويوضح السطران الأخيران من سجل الدمج السبب تمامًا:
.NET Framework Version: 2.0.50727.3521
---
Attempting to load assembly: Rhino.Mocks, Version=3.5.0.1337, Culture=neutral, PublicKeyToken=0b3305902db7183f
Successfully loaded assembly: Rhino.Mocks, Version=3.5.0.1337, Culture=neutral, PublicKeyToken=0b3305902db7183f
---
Attempting to load assembly: Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f
Assembly binding for failed:
System.IO.FileLoadException: Could not load file or assembly 'Rhino.Mocks, Version=3.5.0.1336, Culture=neutral,
PublicKeyToken=0b3305902db7183f' or one of its dependencies. The located assembly's manifest definition
does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f'
=== Pre-bind state information ===
LOG: User = Phoenix\Dani
LOG: DisplayName = Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f
(Fully-specified)
LOG: Appbase = [...]
LOG: Initial PrivatePath = NULL
Calling assembly : AssemblyBinding, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v2.0.50727\config\machine.config.
LOG: Post-policy reference: Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f
LOG: Attempting download of new URL [...].
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
أعتقد أن مصدر هذا الالتباس ربما يرجع إلى أن Microsoft كانت تهدف في الأصل إلى أن تكون أكثر تساهلاً في هذه المطابقة الصارمة لإصدار التجميع الكامل، من خلال المطابقة فقط على أجزاء الإصدار الرئيسية والثانوية:
"عند تحميل مجموعة ، ستجد CLR تلقائيًا أحدث إصدار من الخدمة المثبتة التي تتطابق مع الإصدار الرئيسي/الثانوي من التجميع المطلوب." - جيفري ريختر ، [CLR عبر C# (الطبعة الثانية)] ص.56
كان هذا هو السلوك في الإصدار التجريبي 1 من الإصدار 1.0 CLR، ولكن تمت إزالة هذه الميزة قبل الإصدار 1.0، ولم تتمكن من الظهور مرة أخرى في الإصدار .NET 2.0:
"ملحوظة:لقد وصفت للتو كيف يجب أن تفكر في أرقام الإصدار.لسوء الحظ ، لا يعامل CLR أرقام الإصدار بهذه الطريقة.في .NET 2.0] ، يعامل CLR رقم الإصدار كقيمة غير شفافة ، وإذا كان التجميع يعتمد على الإصدار 1.2.3.4 من مجموعة أخرى ، يحاول CLR تحميل الإصدار 1.2.3.4 فقط (ما لم يكن إعادة توجيه الربط في المكان ).لكن، تخطط Microsoft لتغيير اللودر من CLR في إصدار مستقبلي بحيث تقوم بتحميل أحدث إنشاء/مراجعة لإصدار كبير/صغير من التجميع.على سبيل المثال ، في إصدار مستقبلي من CLR ، إذا كان المحمل يحاول العثور على الإصدار 1.2.3.4 من التجميع والإصدار 1.2.5.0 ، فإن المحمل مع التقاط أحدث إصدار من الخدمة.سيكون هذا تغييرًا موضع ترحيب للغاية في برنامج Loader الخاص بـ CLR - لا يمكنني الانتظار ". - جيفري ريختر ، [CLR عبر C# (الطبعة الثانية)] ص.164 (التركيز الألغام)
نظرًا لأن هذا التغيير لم يتم تنفيذه بعد، أعتقد أنه من الآمن افتراض أن Microsoft قد تراجعت عن هذه النية، وربما فات الأوان لتغيير هذا الآن.حاولت البحث في الويب لمعرفة ما حدث لهذه الخطط، لكن لم أتمكن من العثور على أي إجابات.ما زلت أرغب في الوصول إلى الجزء السفلي منه.
لذلك قمت بإرسال بريد إلكتروني إلى جيف ريختر وسألته مباشرة - اعتقدت أنه إذا كان أي شخص يعرف ما حدث، فسيكون هو.
لقد أجاب في غضون 12 ساعة، في صباح يوم سبت على الأقل، وأوضح أن مُحمل .NET 1.0 Beta 1 قام بالفعل بتنفيذ آلية "التقدم التلقائي" لالتقاط أحدث إصدار متاح ومراجعة للتجميع، ولكن هذا السلوك كان غير مقبول. تم إرجاعه قبل شحن .NET 1.0.كان المقصود لاحقًا إحياء هذا ولكنه لم يتم تنفيذه قبل شحن CLR 2.0.ثم جاء Silverlight، الذي كان له الأولوية لفريق CLR، لذلك تأخرت هذه الوظيفة أكثر.في هذه الأثناء، معظم الأشخاص الذين كانوا متواجدين في أيام CLR 1.0 Beta 1 قد انتقلوا منذ ذلك الحين، لذا فمن غير المرجح أن يرى هذا ضوء النهار، على الرغم من كل العمل الشاق الذي تم بذله بالفعل.
ويبدو أن السلوك الحالي موجود ليبقى.
تجدر الإشارة أيضًا من مناقشتي مع Jeff إلى أن AssemblyFileVersion تمت إضافته فقط بعد إزالة آلية "التمرير التلقائي للأمام" - لأنه بعد 1.0 Beta 1، كان أي تغيير في AssemblyVersion بمثابة تغيير جذري لعملائك، وكان هناك بعد ذلك لا يوجد مكان لتخزين رقم البناء الخاص بك بأمان.يعد AssemblyFileVersion ذلك الملاذ الآمن، حيث أنه لا يتم فحصه تلقائيًا بواسطة CLR.ربما يكون الأمر أكثر وضوحًا بهذه الطريقة، مع وجود رقمين منفصلين للإصدار، مع معاني منفصلة، بدلاً من محاولة إجراء هذا الفصل بين الأجزاء الرئيسية/الثانوية (المنفصلة) وأجزاء البناء/المراجعة (غير المنفصلة) من AssemblyVersion.
الخط السفلي:فكر جيدًا عند تغييرك AssemblyVersion
المغزى من ذلك هو أنه إذا كنت تقوم بشحن تجميعات سيشير إليها مطورون آخرون، فيجب أن تكون حذرًا للغاية بشأن متى تقوم (ولا تقوم بتغيير) تغيير إصدار التجميع لتلك التجميعات.أي تغييرات على AssemblyVersion ستعني أنه سيتعين على مطوري التطبيقات إما إعادة الترجمة مقابل الإصدار الجديد (لتحديث إدخالات AssemblyRef) أو استخدام عمليات إعادة توجيه ربط التجميع لتجاوز الربط يدويًا.
- لا قم بتغيير AssemblyVersion لإصدار الخدمة الذي يهدف إلى أن يكون متوافقًا مع الإصدارات السابقة.
- يفعل قم بتغيير AssemblyVersion لإصدار تعرف أنه يحتوي على تغييرات معطلة.
ما عليك سوى إلقاء نظرة أخرى على سمات الإصدار على mscorlib:
// Assembly mscorlib, Version 2.0.0.0
[assembly: AssemblyFileVersion("2.0.50727.3521")]
[assembly: AssemblyInformationalVersion("2.0.50727.3521")]
[assembly: AssemblyVersion("2.0.0.0")]
لاحظ أن AssemblyFileVersion هو الذي يحتوي على جميع معلومات الخدمة المثيرة للاهتمام (إنه جزء المراجعة من هذا الإصدار الذي يخبرك بحزمة الخدمة التي تستخدمها)، وفي الوقت نفسه تم إصلاح AssemblyVersion على الإصدار القديم الممل 2.0.0.0.أي تغيير في AssemblyVersion سيجبر كل تطبيق .NET يشير إلى mscorlib.dll على إعادة الترجمة مقابل الإصدار الجديد!
AssemblyVersion يبقى إلى حد كبير داخليًا لـ .NET، بينما AssemblyFileVersion هو ما يراه ويندوز.إذا ذهبت إلى خصائص التجميع الموجود في الدليل وقمت بالتبديل إلى علامة تبويب الإصدار، فسيتم العثور على AssemblyFileVersion هو ما ستراه في الأعلى.إذا قمت بفرز الملفات حسب الإصدار، فهذا هو ما يستخدمه Explorer.
ال AssemblyInformationalVersion يتم تعيينه إلى "إصدار المنتج" ومن المفترض أن يكون "مستخدمًا بواسطة الإنسان" تمامًا.
AssemblyVersion هو بالتأكيد الأهم، لكنني لن أتخطيه AssemblyFileVersion, ، أيضاً.إذا كنت لا توفر AssemblyInformationalVersion, ، يضيفها لك المترجم عن طريق إزالة جزء "المراجعة" من رقم الإصدار الخاص بك وترك الملف Major.minor.build.
AssemblyInformationalVersion و AssemblyFileVersion يتم عرضها عند عرض معلومات "الإصدار" لملف من خلال Windows Explorer من خلال عرض خصائص الملف.يتم تجميع هذه السمات فعليًا في ملف VERSION_INFO المورد الذي تم إنشاؤه بواسطة المترجم.
AssemblyInformationalVersion هي قيمة "إصدار المنتج". AssemblyFileVersion هي قيمة "إصدار الملف".
ال AssemblyVersion خاص بتجميعات .NET ويستخدمه مُحمل تجميع .NET لمعرفة إصدار التجميع المطلوب تحميله/ربطه في وقت التشغيل.
ومن بين هذه العناصر، الشيء الوحيد المطلوب تمامًا بواسطة .NET هو AssemblyVersion يصف.لسوء الحظ، يمكن أن يسبب أيضًا معظم المشكلات عندما يتغير بشكل عشوائي، خاصة إذا كنت قويًا في تسمية التجميعات الخاصة بك.
للحفاظ على هذا السؤال الحالي، يجدر تسليط الضوء على ذلك AssemblyInformationalVersion يتم استخدامه بواسطة NuGet ويعكس نسخة الحزمة بما في ذلك أي لاحقة ما قبل النشر.
على سبيل المثال، إصدار AssemblyVersion 1.0.3.* تم حزمه مع dotnet-cli الأساسية لـ asp.net
dotnet pack --version-suffix ci-7 src/MyProject
يُنتج حزمة بالإصدار 1.0.3-ci-7 والتي يمكنك فحصها بالانعكاس باستخدام:
CustomAttributeExtensions.GetCustomAttribute<AssemblyInformationalVersionAttribute>(asm);
ومن الجدير بالذكر بعض الأشياء الأخرى:
1) كما هو موضح في مربع حوار خصائص مستكشف Windows لملف التجميع الذي تم إنشاؤه، هناك مكانان يسمى "إصدار الملف".ما يظهر في رأس مربع الحوار يعرض AssemblyVersion، وليس AssemblyFileVersion.
في قسم معلومات الإصدار الآخر، يوجد عنصر آخر يسمى "إصدار الملف".هذا هو المكان الذي يمكنك فيه رؤية ما تم إدخاله باسم AssemblyFileVersion.
2) AssemblyFileVersion هو مجرد نص عادي.ليس من الضروري أن يتوافق مع قيود نظام الترقيم التي يقوم بها AssemblyVersion (<build> <65K، على سبيل المثال).يمكن أن يكون 3.2.<نص علامة الإصدار>.<التاريخ والوقت>، إذا أردت.سيتعين على نظام البناء الخاص بك ملء الرموز المميزة.
علاوة على ذلك، فهو لا يخضع لاستبدال حرف البدل الموجود في AssemblyVersion.إذا كان لديك فقط قيمة "3.0.1.*" في AssemblyInfo.cs، فهذا هو بالضبط ما سيظهر في معلومات الإصدار الأخرى->عنصر إصدار الملف.
3) لا أعرف تأثير استخدام شيء آخر غير أرقام إصدارات الملفات الرقمية على المثبت.
عندما يتم تغيير عملية تجميع التجميع ، إذا كان لها اسم قوي ، يجب إعادة ترجمة التجميعات المرجعية ، وإلا فإن التجميع لا يتم تحميله!إذا لم يكن له اسم واضح، وإذا لم تتم إضافته بشكل صريح إلى ملف المشروع، فلن يتم نسخه إلى دليل الإخراج عند الإنشاء، لذلك قد تفوت التجميعات المعتمدة، خاصة بعد تنظيف دليل الإخراج.
