Tại sao các phiên bản khác nhau của các hội đồng Silverlight có cùng số phiên bản?

Question

Tại sao các phiên bản khác nhau của các hội đồng Silverlight có cùng số phiên bản?

Location: ...\Silverlight\v3.0\System.Core.dll 
Name: System.Core, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e 

Location: ...\Silverlight\v4.0\System.Core.dll 
Name: System.Core, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e 

Location: ...\Silverlight\v4.0\Profile\WindowsPhone\System.Core.dll 
Name: System.Core, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e 

Trong khi .net tiêu chuẩn có số phiên bản khác nhau

Location: ...\Framework\v4.0.30319\System.dll 
Name: System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 

Location: ...\Framework\v2.0.50727\System.dll 
Name: System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 

Answer 1

Có gì ngăn cản khuôn khổ Silverlight 4 từ sử dụng phiên bản 2.0.5.0 của System.Core là. Khuôn khổ .NET 3.5 đi kèm với phiên bản 2.0 của System.Web. Tuy nhiên, khung công tác .NET 4 có một phiên bản mới hơn của System.Core.

Answer 2

Tôi nghĩ nhóm phát triển quên thay đổi số phiên bản và không có danh sách kiểm tra, nhưng tôi không chắc chắn 100%. Không có cơ chế tự động hóa nhiệm vụ này b/c không có trình biên dịch trung tâm. Mỗi người dùng trong nhóm phát triển này có thể biên dịch tập hợp mã này miễn là họ có tên mạnh với mã thông báo khóa công khai. Tôi quan tâm đến câu trả lời hoàn chỉnh từ một chuyên gia về chủ đề này.

Answer 3

Có lẽ họ không muốn các nhà phát triển phải biên dịch lại ứng dụng Silverlight để nhắm mục tiêu phiên bản khác của Sliverlight Khung ...

Answer 4

Điều chính xác tương tự xảy ra với các thư viện lớp cơ sở (như System.dll) cho máy tính để bàn các phiên bản .NET 2.0, 2.0SP1, 2.0SP2, 3.0, 3.0SP1, 3.5 và 3.5SP1, tất cả đều có cùng [AssemblyVersion], 2.0.0.0. Không cho đến khi .NET 4.0 thực hiện phiên bản này, hãy truy cập 4.0.0.0

Phiên bản lắp ráp đại diện cho giao diện công khai của một hội đồng. Một thay đổi đột phá trong các thành viên loại có thể truy cập đến các hội đồng khác yêu cầu [AssemblyVersion] mới. Nhất thiết như vậy, bởi vì điều đó yêu cầu mã máy khách sử dụng các kiểu này để được biên dịch lại. Tôi đã kiểm tra các phiên bản System.Core.dll mà bạn đã đề cập. Bit của một slog đau đớn thông qua đầu ra xuất khẩu Reflector cho lắp ráp. Nhiều thay đổi trong các lớp và phương thức riêng và nội bộ. Nhưng không phải là công khai, cùng loại và phương pháp.

Không hoàn toàn đúng và điều này cũng xảy ra trong phiên bản dành cho máy tính để bàn, lớp StrongBox có được hàm tạo mặc định trong phiên bản 4.0. Tiết kiệm ân huệ có lẽ là hàm tạo được ghi nhận là "API này hỗ trợ cơ sở hạ tầng .NET Framework và không có ý định sử dụng trực tiếp từ mã của bạn." Và đặc biệt trong Silverlight, một ứng dụng nhắm mục tiêu 4.0 sẽ không bao giờ gặp phiên bản 3.0 của lớp đó một cách tình cờ, không giống như trường hợp máy tính để bàn.

Answer 5

Với .NET, cho một hội đồng đã ký (.snk), lý do đầu tiên tại sao bạn không thay đổi số phiên bản lắp ráp là đảm bảo tên mạnh của hội đồng sẽ vẫn giữ nguyên. Bằng cách này, không gây rối với các tệp .config hoặc các chính sách tùy chỉnh, bất kỳ ứng dụng khách nào được xây dựng với tham chiếu đến assembly của bạn sẽ vẫn có thể tải mà không cần phàn nàn.

Theo mặc định (không xác định assemblies redirections), nếu bạn thay đổi phiên bản, tên mạnh của hội đồng của bạn cũng sẽ được thay đổi và tất cả các phiên bản hiện có được xây dựng dựa trên phiên bản trước sẽ không chạy được.

Nếu bạn không bao giờ thay đổi phiên bản, tất nhiên, bạn sẽ phải đảm bảo rằng bạn không chia sẻ cùng một ứng dụng này với các lớp hoặc phương thức chữ ký khác nhau.

Đó là lý do tại sao phần lớn thời gian, nhà phát triển có xu hướng giữ cùng phiên bản ... mãi mãi, khi có thể, và điều này đúng với CoreCLR (CLR của Silverlight) cũng như .NET CLR.

Trong trường hợp của NET CLR, mặc dù thực tế là họ đã thay đổi phiên bản thực sự đặt ra một số vấn đề cho các ứng dụng .NET hiện có. Đôi khi, .NET hiện có 2 ứng dụng cần để thêm video này vào file .config trong một bối cảnh NET 4:

<configuration> 
    <startup> 
    <supportedRuntime version="v4.0.30319" /> 
    </startup> 
</configuration> 

Bạn có thể nhìn vào bài viết này giải thích cách phức tạp tất cả điều này có thể đằng sau những cảnh: Version Compatibility in the .NET Framework