มีแอตทริบิวต์รุ่นประกอบสามอย่าง ความแตกต่างคืออะไร? ไม่เป็นไรถ้าฉันใช้AssemblyVersionและเพิกเฉยต่อคนที่เหลือ?

MSDN พูดว่า:

• AssemblyVersion :

  ระบุเวอร์ชันของชุดประกอบที่มีการระบุ

• AssemblyFileVersion :

  สั่งให้คอมไพเลอร์ใช้หมายเลขรุ่นเฉพาะสำหรับทรัพยากรเวอร์ชั่นของไฟล์ Win32 รุ่นของไฟล์ Win32 ไม่จำเป็นต้องเหมือนกับหมายเลขเวอร์ชั่นของชุดประกอบ

• AssemblyInformationalVersion :

  กำหนดข้อมูลรุ่นเพิ่มเติมสำหรับรายการประกอบ

นี่คือการติดตามการปฏิบัติที่ดีที่สุดสำหรับการใช้คุณสมบัติแอสเซมบลีคืออะไร

AssemblyVersion

ชุดประกอบอื่น ๆ ที่อ้างอิงชุดประกอบของคุณจะมีลักษณะอย่างไร หากหมายเลขนี้เปลี่ยนแปลงชุดประกอบอื่น ๆ จะต้องอัปเดตการอ้างอิงไปยังชุดประกอบของคุณ! อัปเดตเฉพาะเวอร์ชันนี้หากแบ่งความเข้ากันได้แบบย้อนหลัง AssemblyVersionเป็นสิ่งจำเป็น

ฉันจะใช้รูปแบบ: MAJOR.MINOR สิ่งนี้จะส่งผลให้:

[assembly: AssemblyVersion("1.0")]

หากคุณกำลังติดตามSemVerอย่างเคร่งครัดนี่หมายความว่าคุณจะอัปเดตเมื่อมีการเปลี่ยนแปลงครั้งสำคัญเท่านั้นดังนั้น 1.0, 2.0, 3.0 และอื่น ๆ

AssemblyFileVersion

ใช้สำหรับการปรับใช้ คุณสามารถเพิ่มจำนวนนี้สำหรับการปรับใช้ทุกครั้ง มันถูกใช้โดยโปรแกรมติดตั้ง ใช้มันเพื่อทำเครื่องหมายชุดประกอบที่มีเหมือนกันAssemblyVersionแต่ถูกสร้างขึ้นจากบิลด์ที่ต่างกัน

ใน Windows สามารถดูได้ในคุณสมบัติไฟล์

AssemblyFileVersion เป็นทางเลือก หากไม่ได้รับจะใช้ AssemblyVersion

ฉันใช้รูปแบบ: major.minor.patch.buildที่ฉันติดตามSemVerสำหรับสามส่วนแรกและใช้หมายเลขบิลด์ของ buildserver สำหรับส่วนสุดท้าย (0 สำหรับบิลด์ในเครื่อง) สิ่งนี้จะส่งผลให้:

[assembly: AssemblyFileVersion("1.3.2.254")]

ระวังว่าSystem.Versionตั้งชื่อส่วนเหล่านี้ว่าmajor.minor.build.revision!

AssemblyInformationalVersion

แอสเซมบลีรุ่นผลิตภัณฑ์ นี่คือรุ่นที่คุณจะใช้เมื่อพูดคุยกับลูกค้าหรือเพื่อแสดงบนเว็บไซต์ของคุณ รุ่นนี้อาจเป็นสตริงเช่น ' 1.0 Release Candidate '

AssemblyInformationalVersionเป็นตัวเลือก หากไม่ได้รับจะใช้ AssemblyFileVersion

ฉันจะใช้รูปแบบ: MAJOR.MINOR [.patch] [แก้ไขเป็นสตริง] สิ่งนี้จะส่งผลให้:

[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มีวัตถุประสงค์เพื่อระบุตัวตนของการสร้างของการชุมนุมของแต่ละบุคคล

โดยทั่วไปคุณจะตั้ง Major และ Minor AssemblyFileVersion ด้วยตนเองเพื่อให้สอดคล้องกับเวอร์ชันของชุดประกอบจากนั้นเพิ่ม Build และ / หรือ Revision ทุกครั้งที่ระบบประกอบของคุณคอมไพล์ชุดประกอบ AssemblyFileVersion ควรอนุญาตให้คุณระบุโครงสร้างของแอสเซมบลีที่ไม่ซ้ำกันเพื่อให้คุณสามารถใช้เป็นจุดเริ่มต้นสำหรับการดีบักปัญหาใด ๆ

ในโครงการปัจจุบันของฉันเรามีการสร้างเซิร์ฟเวอร์เข้ารหัสหมายเลขรายการการเปลี่ยนแปลงจากแหล่งเก็บข้อมูลการควบคุมของเราลงในส่วนการสร้างและการแก้ไขของ AssemblyFileVersion สิ่งนี้ทำให้เราสามารถแมปโดยตรงจากแอสเซมบลีไปยังซอร์สโค้ดของมันสำหรับแอสเซมบลีใด ๆ ที่สร้างโดยเซิร์ฟเวอร์การสร้าง (โดยไม่ต้องใช้ป้ายชื่อหรือสาขาในการควบคุมแหล่งที่มา

หมายเลขรุ่นนี้ถูกเก็บไว้ในทรัพยากรรุ่น Win32 และสามารถดูได้เมื่อดูหน้าคุณสมบัติ Windows Explorer สำหรับแอสเซมบลี

CLR ไม่สนใจหรือตรวจสอบ AssemblyFileVersion

AssemblyInformationalVersionมีจุดมุ่งหมายเพื่อเป็นตัวแทนของรุ่นของผลิตภัณฑ์ทั้งหมดของคุณ

AssemblyInformationalVersion มีวัตถุประสงค์เพื่อให้การกำหนดเวอร์ชันที่สอดคล้องกันของผลิตภัณฑ์ทั้งหมดซึ่งอาจประกอบด้วยแอสเซมบลีจำนวนมากที่เป็นเวอร์ชันอิสระอาจมีนโยบายการกำหนดเวอร์ชันที่แตกต่างกันและอาจพัฒนาโดยทีมที่แตกต่างกัน

“ ตัวอย่างเช่นผลิตภัณฑ์เวอร์ชัน 2.0 อาจมีชุดประกอบหลายชุด หนึ่งในแอสเซมบลีเหล่านี้ถูกทำเครื่องหมายเป็นรุ่น 1.0 เนื่องจากเป็นแอสเซมบลีใหม่ที่ไม่ได้จัดส่งในเวอร์ชัน 1.0 ของผลิตภัณฑ์เดียวกัน โดยทั่วไปคุณตั้งค่าชิ้นส่วนหลักและรองของหมายเลขรุ่นนี้เพื่อเป็นตัวแทนรุ่นสาธารณะของผลิตภัณฑ์ของคุณ จากนั้นคุณเพิ่มส่วนการสร้างและการแก้ไขในแต่ละครั้งที่คุณบรรจุผลิตภัณฑ์ที่สมบูรณ์พร้อมชุดประกอบทั้งหมด” - Jeffrey Richter, [CLR ผ่าน C # (Second Edition)] p. 57

CLR ไม่สนใจหรือตรวจสอบ AssemblyInformationalVersion

AssemblyVersionเป็นรุ่นเดียวที่ใส่ใจเกี่ยวกับ CLR ( แต่มันใส่ใจเกี่ยวกับทั้งหมดAssemblyVersion)

AssemblyVersion ถูกใช้โดย CLR เพื่อเชื่อมโยงกับชุดประกอบที่ตั้งชื่ออย่างยิ่ง มันถูกเก็บไว้ในตาราง AssemblyDef รายการข้อมูลเมตาของแอสเซมบลีที่สร้างขึ้นและในตาราง AssemblyRef ของแอสเซมบลีใด ๆ ที่อ้างอิง

สิ่งนี้สำคัญมากเพราะหมายความว่าเมื่อคุณอ้างอิงชุดประกอบที่มีชื่ออย่างยิ่งคุณจะต้องผูกพันกับแอสเซมบลีรุ่นเฉพาะของแอสเซมบลีนั้นอย่างแน่นหนา AssemblyVersion ทั้งหมดจะต้องตรงกันทั้งหมดเพื่อให้การเชื่อมสำเร็จ ตัวอย่างเช่นถ้าคุณอ้างอิงรุ่น 1.0.0.0 ของแอสเซมบลีที่ตั้งชื่ออย่างยิ่งที่ build-time แต่เฉพาะแอสเซมบลีนั้นเวอร์ชัน 1.0.0.1 เท่านั้นที่พร้อมใช้งานในขณะใช้งานการเชื่อมโยงจะล้มเหลว! (จากนั้นคุณจะต้องแก้ไขปัญหานี้โดยใช้การเปลี่ยนเส้นทาง Assembly Binding )

ความสับสนเกี่ยวกับว่าทั้งหมดAssemblyVersionจะต้องตรงกับ (ใช่.)

มีความสับสนเล็กน้อยเกี่ยวกับว่า AssemblyVersion ทั้งหมดจะต้องตรงกันทั้งหมดเพื่อให้สามารถโหลดชุดประกอบได้หรือไม่ บางคนอยู่ภายใต้ความเชื่อที่ผิด ๆ ว่ามีเพียงส่วนหลักและส่วนย่อยของ 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 ตั้งใจที่จะผ่อนปรนในการจับคู่ AssemblyVersion ที่เข้มงวดนี้โดยการจับคู่เฉพาะในรุ่น Major และ Minor:

“ เมื่อโหลดแอสเซมบลี CLR จะค้นหาเวอร์ชันการให้บริการที่ติดตั้งล่าสุดโดยอัตโนมัติซึ่งตรงกับเวอร์ชันหลัก / รองของแอสเซมบลีที่ถูกร้องขอ” - Jeffrey Richter, [CLR ผ่าน C # (Second Edition)] p. 56

นี่เป็นพฤติกรรมในเบต้า 1 ของ 1.0 CLR อย่างไรก็ตามคุณลักษณะนี้ถูกลบออกก่อนการเปิดตัว 1.0 และไม่ได้จัดการให้ปรากฏขึ้นอีกครั้งใน. NET 2.0:

“ หมายเหตุ: ฉันเพิ่งอธิบายว่าคุณควรคิดถึงหมายเลขรุ่นอย่างไร น่าเสียดายที่ CLR ไม่ได้จัดการกับหมายเลขเวอร์ชันด้วยวิธีนี้ [ใน. NET 2.0], CLR จะถือว่าหมายเลขรุ่นเป็นค่าทึบและถ้าแอสเซมบลีขึ้นอยู่กับรุ่น 1.2.3.4 ของแอสเซมบลีอื่น CLR พยายามโหลดรุ่น 1.2.3.4 เท่านั้น (เว้นแต่ว่ามีการเปลี่ยนเส้นทางการผูกไว้ ) อย่างไรก็ตาม ไมโครซอฟท์มีแผนที่จะเปลี่ยนโหลดเดอร์ของ CLR ในเวอร์ชันอนาคตเพื่อให้สามารถโหลดบิวด์การสร้าง / การแก้ไขล่าสุดสำหรับแอสเซมบลีรุ่นหลัก / รองที่กำหนด. ตัวอย่างเช่นในเวอร์ชันอนาคตของ CLR หากตัวโหลดพยายามค้นหาเวอร์ชัน 1.2.3.4 ของแอสเซมบลีและเวอร์ชัน 1.2.5.0 มีอยู่ตัวโหลดที่พร้อมรับเวอร์ชันการให้บริการล่าสุดโดยอัตโนมัติ นี่จะเป็นการเปลี่ยนแปลงที่น่ายินดีมากสำหรับตัวโหลด CLR - ฉันรอไม่ไหวแล้ว” - Jeffrey Richter, [CLR ผ่าน C # (Second Edition)] p. 164 (เหมืองเน้น)

เนื่องจากการเปลี่ยนแปลงนี้ยังไม่ได้รับการดำเนินการฉันคิดว่ามันปลอดภัยที่จะสมมติว่า Microsoft มีการติดตามย้อนกลับเกี่ยวกับความตั้งใจนี้และอาจช้าเกินไปที่จะเปลี่ยนแปลงในตอนนี้ ฉันพยายามค้นหาทางเว็บเพื่อค้นหาว่าเกิดอะไรขึ้นกับแผนเหล่านี้ แต่ฉันไม่พบคำตอบ ฉันยังต้องการที่จะไปที่ด้านล่างของมัน

ดังนั้นฉันจึงส่งอีเมล Jeff Richter และถามเขาโดยตรง - ฉันคิดว่าถ้าใครรู้ว่าเกิดอะไรขึ้นมันจะเป็นเขา

เขาตอบกลับภายใน 12 ชั่วโมงในเช้าวันเสาร์ไม่น้อยและชี้แจงว่าตัวโหลด. NET 1.0 Beta 1 ได้ใช้กลไก 'roll-forward-forward' นี้โดยอัตโนมัติเพื่อรับ Build และ Revision ของแอสเซมบลีล่าสุด แต่พฤติกรรมนี้ ย้อนกลับก่อนที่จะส่ง. NET 1.0 ภายหลังมีวัตถุประสงค์เพื่อฟื้นฟูสิ่งนี้ แต่ไม่ได้ทำก่อนที่จะส่ง CLR 2.0 จากนั้น Silverlight มาซึ่งให้ความสำคัญกับทีม CLR ดังนั้นการทำงานนี้จึงล่าช้าออกไปอีก ในขณะเดียวกันผู้คนส่วนใหญ่ที่อยู่ในยุค CLR 1.0 Beta 1 ได้ย้ายมาตั้งแต่ดังนั้นจึงไม่น่าที่สิ่งนี้จะเห็นแสงของวันแม้จะมีการทำงานหนักทั้งหมดที่ได้ใส่เข้าไปแล้ว

ดูเหมือนว่าพฤติกรรมปัจจุบันจะอยู่ที่นี่

นอกจากนี้ยังเป็นที่น่าสังเกตจากการสนทนาของฉันกับเจฟฟ์ว่า AssemblyFileVersion ถูกเพิ่มเข้ามาหลังจากการลบกลไก 'roll-forward' โดยอัตโนมัติหลังจากที่ 1.0 Beta 1 การเปลี่ยนแปลงใด ๆ ของ AssemblyVersion นั้นเป็นการเปลี่ยนแปลงที่ไม่ดีสำหรับลูกค้าของคุณ ไม่มีที่เก็บหมายเลขการสร้างของคุณอย่างปลอดภัย AssemblyFileVersion นั้นเป็นสวรรค์ที่ปลอดภัยเนื่องจาก CLR ไม่เคยตรวจสอบโดยอัตโนมัติ บางทีอาจเป็นเรื่องที่ชัดเจนกว่านั้นโดยมีหมายเลขรุ่นสองหมายเลขแยกกันโดยมีความหมายแยกต่างหากแทนที่จะพยายามแยกดังกล่าวระหว่าง Major / Minor (แบ่ง) และ Build / Revision (ไม่ทำลาย) ของ AssemblyVersion

บรรทัดล่าง: คิดอย่างรอบคอบเมื่อคุณเปลี่ยน 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 ที่มีข้อมูลการบริการที่น่าสนใจทั้งหมด (เป็นส่วนการแก้ไขของรุ่นนี้ที่จะบอกคุณว่าคุณกำลังใช้ Service Pack อยู่) ในขณะที่ AssemblyVersion นั้นได้รับการแก้ไขที่เก่าน่าเบื่อ 2.0.0.0 การเปลี่ยนแปลงใด ๆ ใน AssemblyVersion จะบังคับให้แอปพลิเคชัน. NET ทุกตัวที่อ้างอิง mscorlib.dll เพื่อรวบรวมใหม่กับเวอร์ชันใหม่!

AssemblyVersionค่อนข้างอยู่ภายใน. NET ในขณะที่AssemblyFileVersionเป็นสิ่งที่ Windows เห็น หากคุณไปที่คุณสมบัติของแอสเซมบลีที่อยู่ในไดเรกทอรีและสลับไปที่แท็บเวอร์ชันนี่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. * ที่บรรจุด้วย asp.net core dotnet-cli

dotnet pack --version-suffix ci-7 src/MyProject

สร้างแพ็คเกจด้วยเวอร์ชัน 1.0.3-ci-7 ซึ่งคุณสามารถตรวจสอบด้วยการสะท้อนโดยใช้:

CustomAttributeExtensions.GetCustomAttribute<AssemblyInformationalVersionAttribute>(asm);

มันคุ้มค่าที่จะสังเกตสิ่งอื่น ๆ :

1) ดังที่แสดงในกล่องโต้ตอบคุณสมบัติ Windows Explorer สำหรับแอสเซมบลีไฟล์ที่สร้างขึ้นมีสองตำแหน่งที่เรียกว่า "เวอร์ชันไฟล์" สิ่งที่เห็นในส่วนหัวของกล่องโต้ตอบแสดง AssemblyVersion ไม่ใช่ AssemblyFileVersion

ในส่วนข้อมูลรุ่นอื่น ๆ มีองค์ประกอบอื่นที่เรียกว่า "เวอร์ชันไฟล์" ที่นี่คุณสามารถเห็นสิ่งที่ถูกป้อนเป็น AssemblyFileVersion

2) AssemblyFileVersion เป็นเพียงข้อความธรรมดา ไม่จำเป็นต้องเป็นไปตามข้อ จำกัด โครงร่างหมายเลขที่ AssemblyVersion ทำ (<build> <65K เช่น) สามารถเป็น 3.2. <release tag text>. <datetime> หากคุณต้องการ ระบบการสร้างของคุณจะต้องกรอกโทเค็น

ยิ่งไปกว่านั้นมันไม่อยู่ภายใต้การแทนที่สัญลักษณ์ตัวแทนที่ AssemblyVersion หากคุณเพียงแค่มีค่า "3.0.1. *" ใน AssemblyInfo.cs นั่นคือสิ่งที่จะแสดงในองค์ประกอบรุ่นข้อมูลอื่น ๆ -> ไฟล์เวอร์ชัน

3) ฉันไม่ทราบว่ามีผลกระทบอะไรกับตัวติดตั้งในการใช้อย่างอื่นนอกเหนือจากหมายเลขเวอร์ชันไฟล์ตัวเลข

เมื่อ AssemblyVersion ของแอสเซมบลีเปลี่ยนไปถ้ามีชื่อที่รัดกุมแอสเซมบลีที่อ้างอิงต้องถูก recompiled มิฉะนั้นแอสเซมบลีไม่โหลด หากไม่มีชื่อที่รัดกุมถ้าไม่ได้เพิ่มลงในไฟล์โครงการอย่างชัดเจนไฟล์นั้นจะไม่ถูกคัดลอกไปยังไดเรกทอรีออกเมื่อสร้างดังนั้นคุณอาจพลาดแอสเซมบลีที่ขึ้นอยู่กับโดยเฉพาะอย่างยิ่งหลังจากการทำความสะอาดไดเร็กทอรีเอาต์พุต