it-swarm-vi.tech

Sự khác biệt giữa hộiVersion, hộiFileVersion và hội đồng thông tin là gì?

Có ba thuộc tính phiên bản hội. Sự khác biệt là gì? Có ổn không nếu tôi sử dụng AssemblyVersion và bỏ qua phần còn lại?


MSDN nói:

  • Hội đồng :

    Chỉ định phiên bản của hội được quy kết.

  • HộiFileVersion :

    Hướng dẫn trình biên dịch sử dụng số phiên bản cụ thể cho tài nguyên phiên bản tệp Win32. Phiên bản tệp Win32 không bắt buộc phải giống với số phiên bản của Hội.

  • HộiInInalalVersion :

    Xác định thông tin phiên bản bổ sung cho bảng kê khai hội.


Đây là phần tiếp theo Thực tiễn tốt nhất để sử dụng Thuộc tính hội là gì?

824
Jakub Šturc

Lắp ráp

Trường hợp các hội đồng khác tham chiếu hội của bạn sẽ nhìn. Nếu số này thay đổi, các hội đồng khác phải cập nhật tài liệu tham khảo của họ cho Hội của bạn! AssemblyVersion là bắt buộc.

Tôi sử dụng định dạng: Major.minor. Điều này sẽ dẫn đến:

[Assembly: AssemblyVersion("1.0")]

HộiFileVersion

Được sử dụng để triển khai. Bạn có thể tăng số lượng này cho mỗi lần triển khai. Nó được sử dụng bởi các chương trình thiết lập. Sử dụng nó để đánh dấu các hội đồng có cùng AssemblyVersion, nhưng được tạo từ các bản dựng khác nhau.

Trong Windows, nó có thể được xem trong thuộc tính tệp.

Nếu có thể, hãy để nó được tạo bởi MSBuild. Hội đồng hội thảo là tùy chọn. Nếu không được đưa ra, hội đồng được sử dụng.

Tôi sử dụng định dạng: Major.minor.revision.build, trong đó tôi sử dụng sửa đổi cho giai đoạn phát triển (Alpha, Beta, RC và RTM), gói dịch vụ và sửa lỗi nóng. Điều này sẽ dẫn đến:

[Assembly: AssemblyFileVersion("1.0.3100.1242")]

Hội đồng thông tin

Phiên bản sản phẩm của hội. Đây là phiên bản bạn sẽ sử dụng khi nói chuyện với khách hàng hoặc để hiển thị trên trang web của bạn. Phiên bản này có thể là một chuỗi, như 'Ứng viên phát hành 1.'.

Phân tích mã sẽ khiếu nại về nó (CA2243) - được báo cáo cho Microsoft (không được sửa trong VS2013).

AssemblyInformationalVersion là tùy chọn. Nếu không được đưa ra, hội đồngFileVersion được sử dụng.

Tôi sử dụng định dạng: Major.minor [sửa đổi dưới dạng chuỗi]. Điều này sẽ dẫn đến:

[Assembly: AssemblyInformationalVersion("1.0 RC1")]
871
Rémy van Duijkeren

Phiên bản của các hội đồng trong .NET có thể là một viễn cảnh khó hiểu do hiện tại có ít nhất ba cách để chỉ định một phiên bản cho Hội của bạn.

Dưới đây là ba thuộc tính hội liên quan đến phiên bản chính:

// 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")]

Theo quy ước, bốn phần của phiên bản được gọi là Phiên bản chính , Phiên bản nhỏ , Xây dựng Sửa đổi .

AssemblyFileVersion được dự định để xác định duy nhất một bản dựng của Hội đồng riêng lẻ

Thông thường, bạn sẽ đặt thủ công Hội đồng chính và phụ nhỏ để phản ánh phiên bản của Hội đồng, sau đó tăng Bản dựng và/hoặc Sửa đổi mỗi khi hệ thống xây dựng của bạn biên dịch Hội. Hội đồng hội thảo sẽ cho phép bạn xác định duy nhất một bản dựng của hội, để bạn có thể sử dụng nó làm điểm khởi đầu để gỡ lỗi bất kỳ vấn đề nào.

Trong dự án hiện tại của tôi, chúng tôi có máy chủ xây dựng mã hóa số lượng thay đổi từ kho lưu trữ kiểm soát nguồn của chúng tôi vào các phần Xây dựng và Sửa đổi của Hội đồngFileVersion. Điều này cho phép chúng tôi ánh xạ trực tiếp từ một hội vào mã nguồn của nó, cho bất kỳ hội nào được tạo bởi máy chủ xây dựng (mà không phải sử dụng nhãn hoặc các nhánh trong kiểm soát nguồn hoặc giữ thủ công bất kỳ bản ghi nào của các phiên bản đã phát hành).

Số phiên bản này được lưu trữ trong tài nguyên phiên bản Win32 và có thể được nhìn thấy khi xem các trang thuộc tính Windows Explorer cho Hội.

CLR không quan tâm và cũng không kiểm tra Hội đồngFileVersion.

AssemblyInformationalVersion được dự định đại diện cho phiên bản của toàn bộ sản phẩm của bạn

Hội đồng Thông tin được thiết kế để cho phép phiên bản nhất quán của toàn bộ sản phẩm, có thể bao gồm nhiều hội đồng được phiên bản độc lập, có thể có các chính sách phiên bản khác nhau và có khả năng được phát triển bởi các nhóm khác nhau.

Ví dụ, phiên bản 2.0 của sản phẩm có thể chứa một số cụm; một trong những hội đồng này được đánh dấu là phiên bản 1.0 vì nó là một hội mới mà không có tàu trong phiên bản 1.0 của cùng một sản phẩm. Thông thường, bạn đặt các phần chính và phụ của số phiên bản này để thể hiện phiên bản công khai của sản phẩm. Sau đó, bạn tăng các phần xây dựng và sửa đổi mỗi khi bạn đóng gói một sản phẩm hoàn chỉnh với tất cả các bộ lắp ráp của nó. - - Jeffrey Richter, [CLR qua C # (Ấn bản thứ hai)] p. 57

CLR không quan tâm và cũng không kiểm tra Hội đồng thông tin.

AssemblyVersion là phiên bản duy nhất mà CLR quan tâm (nhưng nó quan tâm đến toàn bộ AssemblyVersion)

Bộ lắp ráp được CLR sử dụng để liên kết với các cụm được đặt tên mạnh. Nó được lưu trữ trong bảng siêu dữ liệu tệp kê khai của Hội đồng được xây dựng và trong bảng Hội đồng của bất kỳ Hội đồng nào tham chiếu nó.

Điều này rất quan trọng, bởi vì điều đó có nghĩa là khi bạn tham chiếu một Hội được đặt tên mạnh mẽ, bạn bị ràng buộc chặt chẽ với một Hội đồng cụ thể của Hội đồng đó. Toàn bộ Hội đồng phải là một kết hợp chính xác để liên kết thành công. Ví dụ: nếu bạn tham chiếu phiên bản 1.0.0.0 của một hội có tên mạnh vào thời gian xây dựng, nhưng chỉ có phiên bản 1.0.0.1 của hội đó có sẵn trong thời gian chạy, ràng buộc sẽ thất bại! (Sau đó, bạn sẽ phải xử lý vấn đề này bằng cách sử dụng Hội nghị chuyển hướng liên kết .)

Nhầm lẫn về việc toàn bộ AssemblyVersion có khớp hay không. (Vâng, đúng vậy.)

Có một chút nhầm lẫn xung quanh việc liệu toàn bộ Hội đồng có phải là một kết hợp chính xác để nạp một hội không. Một số người có niềm tin sai lầm rằng chỉ có các phần Chính và Phần phụ của Hội đồng phải khớp để ràng buộc để thành công. Đây là một giả định hợp lý, tuy nhiên cuối cùng nó không chính xác (kể từ .NET 3.5), và nó tầm thường để xác minh điều này cho phiên bản CLR của bạn. Chỉ cần thực thi mã mẫu này .

Trên máy của tôi, tải hội thứ hai không thành công và hai dòng cuối cùng của nhật ký hợp nhất làm cho nó hoàn toàn rõ ràng tại sao:

.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.

Tôi nghĩ rằng nguồn gốc của sự nhầm lẫn này có lẽ là do Microsoft ban đầu dự định sẽ khoan dung hơn một chút về sự phù hợp chặt chẽ này của Hội đồng đầy đủ, bằng cách chỉ khớp trên các phần của phiên bản Chính và phụ:

Khi tải một hội, CLR sẽ tự động tìm phiên bản dịch vụ được cài đặt mới nhất phù hợp với phiên bản chính/phụ của hội đang được yêu cầu. Hồi - Jeffrey Richter, [CLR qua C # (Ấn bản thứ hai)] p. 56

Đây là hành vi trong bản Beta 1 của 1.0 CLR, tuy nhiên tính năng này đã bị xóa trước khi phát hành bản 1.0 và đã được quản lý để hiển thị lại trong .NET 2.0:

Lưu ý: Tôi vừa mô tả cách bạn nên nghĩ về số phiên bản. Thật không may, CLR không xử lý số phiên bản theo cách này. [Trong .NET 2.0], CLR coi số phiên bản là giá trị mờ và nếu một Hội đồng phụ thuộc vào phiên bản 1.2.3.4 của một Hội đồng khác, CLR chỉ cố gắng tải phiên bản 1.2.3.4 (trừ khi có chuyển hướng ràng buộc ). Tuy nhiên, Microsoft có kế hoạch thay đổi trình tải của CLR trong phiên bản tương lai để tải bản dựng/sửa đổi mới nhất cho phiên bản chính/phụ của một Hội đồng . Ví dụ: trên phiên bản tương lai của CLR, nếu trình tải đang cố gắng tìm phiên bản 1.2.3.4 của Hội và phiên bản 1.2.5.0, trình tải sẽ tự động chọn phiên bản phục vụ mới nhất. Đây sẽ là một thay đổi rất đáng hoan nghênh đối với trình tải CLR - Tôi cho một người có thể chờ đợi. Hãy - Jeffrey Richter, [CLR qua C # (Ấn bản thứ hai)] p. 164 (mỏ nhấn mạnh)

Vì sự thay đổi này vẫn chưa được thực hiện, tôi nghĩ rằng nó an toàn khi cho rằng Microsoft đã theo dõi ngược lại ý định này và có lẽ đã quá muộn để thay đổi điều này ngay bây giờ. Tôi đã cố gắng tìm kiếm trên web để tìm hiểu chuyện gì đã xảy ra với những kế hoạch này, nhưng tôi không thể tìm thấy câu trả lời nào. Tôi vẫn muốn đi đến tận cùng của nó.

Vì vậy, tôi đã gửi email cho Jeff Richter và hỏi anh ta trực tiếp - tôi đoán xem có ai biết chuyện gì đã xảy ra không, đó sẽ là anh ta.

Anh ta đã trả lời trong vòng 12 giờ, vào một buổi sáng thứ bảy không kém, và làm rõ rằng trình tải .NET 1.0 Beta 1 đã thực hiện cơ chế 'tự động chuyển tiếp' này để chọn Bản dựng và Sửa đổi mới nhất của một Hội đồng, nhưng hành vi này là hoàn nguyên trước khi .NET 1.0 xuất xưởng. Sau đó, nó đã được dự định để làm sống lại điều này nhưng nó đã không thực hiện được trước khi CLR 2.0 xuất xưởng. Sau đó đến Silverlight, được ưu tiên cho nhóm CLR, vì vậy chức năng này đã bị trì hoãn hơn nữa. Trong khi đó, hầu hết những người xung quanh trong thời kỳ CLR 1.0 Beta 1 đã chuyển đi, vì vậy, nó không chắc rằng điều này sẽ nhìn thấy ánh sáng trong ngày, bất chấp mọi công việc khó khăn đã được đưa vào.

Hành vi hiện tại, dường như, là ở đây.

Điều đáng chú ý từ cuộc thảo luận của tôi với Jeff rằng HộiFileVersion chỉ được thêm vào sau khi loại bỏ cơ chế 'tự động chuyển tiếp' - bởi vì sau 1.0 Beta 1, mọi thay đổi đối với Hội đồng là một thay đổi đột phá đối với khách hàng của bạn, sau đó không nơi nào để lưu trữ an toàn số xây dựng của bạn. HộiFileVersion là nơi trú ẩn an toàn, vì nó không bao giờ tự động kiểm tra bởi CLR. Có lẽ nó rõ ràng hơn theo cách đó, có hai số phiên bản riêng biệt, với ý nghĩa riêng biệt, thay vì cố gắng phân tách giữa phần Chính/Nhỏ (phá vỡ) và phần Xây dựng/Sửa đổi (không phá vỡ) của Hội đồng.

Điểm mấu chốt: Hãy suy nghĩ cẩn thận khi bạn thay đổi AssemblyVersion của bạn

Về mặt đạo đức là nếu bạn tập hợp các nhóm vận chuyển mà các nhà phát triển khác sẽ tham khảo, bạn cần phải cực kỳ cẩn thận khi bạn thực hiện (và don lồng) thay đổi Lắp ráp của các hội đồng đó. Bất kỳ thay đổi nào đối với Hội đồng sẽ có nghĩa là các nhà phát triển ứng dụng sẽ phải biên dịch lại phiên bản mới (để cập nhật các mục nhập của Hội đồng này) hoặc sử dụng các chuyển hướng liên kết hội để ghi đè thủ công.

  • Không thay đổi Lắp ráp đối với bản phát hành dịch vụ nhằm tương thích ngược.
  • Do thay đổi Hội đồng đối với bản phát hành mà bạn biết có các thay đổi vi phạm.

Chỉ cần xem xét lại các thuộc tính phiên bản trên 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")]

Lưu ý rằng đó là phiên bản hội đồng hội thảo có chứa tất cả các thông tin phục vụ thú vị Mọi thay đổi đối với Hội đồng sẽ buộc mọi ứng dụng .NET tham chiếu mscorlib.dll phải biên dịch lại so với phiên bản mới!

570
Daniel Fortunov

AssemblyVersion khá nhiều nội bộ cho .NET, trong khi AssemblyFileVersion là những gì Windows thấy. Nếu bạn đi đến các thuộc tính của một hội đang ngồi trong một thư mục và chuyển sang tab phiên bản, thì AssemblyFileVersion là thứ bạn sẽ thấy trên cùng. Nếu bạn sắp xếp các tệp theo phiên bản, đây là những gì được Explorer sử dụng.

AssemblyInformationalVersion ánh xạ tới "Phiên bản sản phẩm" và hoàn toàn có nghĩa là "con người sử dụng".

AssemblyVersion chắc chắn là quan trọng nhất, nhưng tôi cũng sẽ không bỏ qua AssemblyFileVersion. Nếu bạn không cung cấp AssemblyInformationalVersion, trình biên dịch sẽ thêm nó cho bạn bằng cách tước phần "sửa đổi" của số phiên bản của bạn và để lại Major.minor.build.

42
Bob King

AssemblyInformationalVersionAssemblyFileVersion được hiển thị khi bạn xem thông tin "Phiên bản" trên tệp thông qua Windows Explorer bằng cách xem thuộc tính tệp. Các thuộc tính này thực sự được biên dịch thành tài nguyên VERSION_INFO được tạo bởi trình biên dịch.

AssemblyInformationalVersion là giá trị "Phiên bản sản phẩm". AssemblyFileVersion là giá trị "Phiên bản tệp".

AssemblyVersion dành riêng cho các hội đồng .NET và được sử dụng bởi trình tải hội đồng .NET để biết phiên bản nào của một hội sẽ tải/liên kết khi chạy.

Trong số này, thứ duy nhất được .NET yêu cầu hoàn toàn là thuộc tính AssemblyVersion. Thật không may, nó cũng có thể gây ra nhiều vấn đề nhất khi nó thay đổi một cách bừa bãi, đặc biệt nếu bạn mạnh mẽ đặt tên cho hội đồng của mình.

21
Scott Dorman

Để giữ cho câu hỏi này hiện tại, cần nhấn mạnh rằng AssemblyInformationalVersion được NuGet sử dụng và phản ánh phiên bản gói bao gồm bất kỳ hậu tố trước khi phát hành.

Ví dụ: Lắp ráp 1.0.3. * Được đóng gói với dotnet-cli lõi asp.net

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

Tạo gói với phiên bản 1.0.3-ci-7 mà bạn có thể kiểm tra bằng phản xạ bằng cách sử dụng:

CustomAttributeExtensions.GetCustomAttribute<AssemblyInformationalVersionAttribute>(asm);
8
KCD

Đáng chú ý một số điều khác:

1) Như được hiển thị trong hộp thoại Thuộc tính Windows Explorer cho tệp Hội đồng được tạo, có hai vị trí được gọi là "Phiên bản tệp". Cái được nhìn thấy trong tiêu đề của hộp thoại hiển thị AssociationVersion, không phải là AssociationFileVersion.

Trong phần Thông tin phiên bản khác, có một yếu tố khác gọi là "Phiên bản tệp". Đây là nơi bạn có thể thấy những gì đã được nhập dưới dạng HộiFileVersion.

2) HộiFileVersion chỉ là văn bản thuần túy. Nó không phải tuân thủ các hạn chế lược đồ đánh số mà Hội đồng thực hiện (<build> <65K, ví dụ :). Nó có thể là 3.2. <Phát hành thẻ văn bản>. <Datetime>, nếu bạn thích. Hệ thống xây dựng của bạn sẽ phải điền vào các mã thông báo.

Hơn nữa, nó không phải là đối tượng thay thế ký tự đại diện mà hộiVersion. Nếu bạn chỉ có một giá trị "3.0.1. *" Trong Hội nghịInfo.cs, đó chính xác là những gì sẽ hiển thị trong thông tin Phiên bản khác-> Phần tử Phiên bản tệp.

3) Tuy nhiên, tôi không biết tác động đến trình cài đặt sử dụng thứ gì đó ngoài số phiên bản tệp số.

7
DavidM

Khi thay đổi lắp ráp của hội đồng, nếu nó có tên mạnh, các hội đồng tham chiếu cần phải được biên dịch lại, nếu không thì hội không tải! Nếu nó không có tên mạnh, nếu không được thêm rõ ràng vào tệp dự án, nó sẽ không được sao chép vào thư mục đầu ra khi xây dựng để bạn có thể bỏ lỡ các cụm tùy chỉnh, đặc biệt là sau khi làm sạch thư mục đầu ra.

2
linquize