Quản lý các bản cập nhật phụ thuộc trong dự án .NET của bạn

Đã hoàn thành

Sớm hay muộn, bạn muốn cập nhật lên phiên bản mới của thư viện. Có thể một hàm được đánh dấu là không được chấp nhận hoặc có thể có một tính năng mới trong phiên bản mới hơn của gói bạn đang sử dụng.

Hãy cân nhắc những điều này trước khi bạn tìm cách cập nhật thư viện:

• Loại bản cập nhật: Có loại bản cập nhật nào? Đây có phải là một bản sửa lỗi nhỏ không? Có phải bạn đang thêm một tính năng mới mà bạn cần? Mã đó có làm hỏng mã của bạn không? Bạn có thể truyền đạt loại bản cập nhật bằng cách sử dụng hệ thống được gọi phiên bản ngữ. Cách số phiên bản của thư viện được thể hiện thông báo cho các nhà phát triển loại cập nhật mà họ đang xử lý.
• liệu dự án có được cấu hình đúngkhông: Bạn có thể cấu hình dự án .NET của mình để chỉ nhận được các loại cập nhật bạn muốn. Bạn chỉ thực hiện cập nhật nếu có sẵn một loại bản cập nhật cụ thể. Chúng tôi khuyên bạn nên sử dụng phương pháp này vì bạn không gặp rủi ro khi gặp phải sự cố bất ngờ.
• vấn đề bảo mật: Quản lý các quan hệ phụ thuộc dự án của bạn theo thời gian liên quan đến việc biết được các vấn đề có thể xảy ra. Vấn đề phát sinh như lỗ hổng được phát hiện, ví dụ. Tốt nhất, các bản vá lỗi được phát hành mà bạn có thể tải xuống. Công cụ .NET Core giúp bạn chạy một kiểm tra thư viện của bạn để tìm hiểu xem bạn có gói cần được cập nhật hay không. Việc này cũng giúp bạn thực hiện hành động thích hợp để khắc phục sự cố.

Sử dụng lập phiên bản ngữ trị

Có một tiêu chuẩn ngành được gọi là phiên bản ngữ nghĩa, đó là cách bạn thể hiện loại thay đổi mà bạn hoặc một số nhà phát triển khác giới thiệu đến một thư viện. Lập phiên bản ngữ nghĩa hoạt động bằng cách đảm bảo rằng gói có số phiên bản và số phiên bản được chia thành các phần sau:

• Bản chính: Số ngoài cùng bên trái. Ví dụ: đó là giá trị 1 trong 1.0.0. Thay đổi đối với số này có nghĩa là bạn có thể gặp phải "các thay đổi phá vỡ" trong mã của mình. Bạn có thể cần phải viết lại một phần mã của mình.
• Phiên bảnphụ: Số giữa. Ví dụ: đó là giá trị 2 trong 1.2.0. Thay đổi đối với số này có nghĩa là các tính năng đã được thêm vào. Mã của bạn sẽ vẫn hoạt động. Thông thường, việc chấp nhận bản cập nhật thường an toàn.
• patch version: The rightmost number. Ví dụ: đó là giá trị 3 trong 1.2.3. Thay đổi đối với số này có nghĩa là một thay đổi đã được áp dụng để khắc phục một số nội dung trong mã sẽ hoạt động. Bạn nên an toàn khi chấp nhận bản cập nhật.

Bảng này minh họa cách số phiên bản thay đổi cho từng loại phiên bản:

Kiểu	Điều gì sẽ xảy ra
Phiên bản chính	1.0.0 đổi thành 2.0.0
Phiên bản phụ	1.1.1 đổi thành 1.2.0
Phiên bản bản vá	1.0.1 đổi thành 1.0.2

Nhiều công ty và nhà phát triển sử dụng hệ thống này. Nếu bạn định phát hành gói và đẩy chúng vào sổ đăng ký NuGet, bạn sẽ theo dõi lập phiên bản ngữ pháp. Ngay cả khi bạn chỉ tải xuống gói từ sổ đăng ký NuGet, bạn có thể mong đợi các gói này theo sau lập phiên bản ngữ pháp.

Thay đổi đối với gói có thể gây rủi ro, bao gồm cả rủi ro lỗi có thể gây hại cho doanh nghiệp của bạn. Một số rủi ro có thể yêu cầu bạn viết lại một phần mã của mình. Viết lại mã mất thời gian và chi phí tiền bạc.

Cập nhật phương pháp

Là nhà phát triển .NET, bạn có thể truyền đạt hành vi cập nhật mà bạn muốn .NET. Hãy nghĩ về việc cập nhật về rủi ro. Dưới đây là một số cách tiếp cận:

• bản chính: Tôi đồng ý với việc cập nhật lên phiên bản chính mới nhất ngay khi phiên bản được phát hành. Tôi chấp nhận thực tế là tôi có thể cần phải thay đổi mã ở phía tôi.
• Phiên bảnphụ: Tôi đồng ý với tính năng mới đang được thêm vào. Tôi không ok với mã mà phá vỡ.
• bản vá: Bản cập nhật duy nhất tôi đồng ý là bản sửa lỗi.

Nếu bạn đang quản lý một dự án .NET mới hoặc nhỏ hơn, bạn có thể đủ khả năng để lỏng lẻo với cách bạn xác định chiến lược cập nhật. Ví dụ: bạn luôn có thể cập nhật lên phiên bản mới nhất. Đối với các dự án phức tạp hơn, sẽ có nhiều sắc thái hơn, nhưng chúng tôi sẽ lưu sắc thái đó cho một mô-đun trong tương lai.

Nhìn chung, sự phụ thuộc bạn đang cập nhật càng nhỏ, thì càng ít quan hệ phụ thuộc và càng có nhiều khả năng quá trình cập nhật trở nên dễ dàng.

Cấu hình tệp dự án để cập nhật

Khi bạn đang thêm một hoặc nhiều phụ thuộc, hãy cấu hình tệp dự án của bạn để bạn có hành vi có thể dự đoán được khi khôi phục, xây dựng hoặc chạy dự án của mình. Bạn có thể truyền đạt cách tiếp cận mà bạn muốn thực hiện cho một gói. NuGet có khái niệm về các phiên và phiên bản và phiên bản trôi nổi.

Phạm vi phiên bản là một ký hiệu đặc biệt mà bạn có thể sử dụng để chỉ ra một phạm vi phiên bản cụ thể mà bạn muốn giải quyết.

Thông báo	Quy tắc đã áp dụng	Sự miêu tả
1.0	x >= 1,0	Phiên bản tối thiểu, bao gồm
(1.0,)	x > 1,0	Phiên bản tối thiểu, độc quyền
[1.0]	x == 1,0	Khớp phiên bản chính xác
(,1.0]	x ≤ 1,0	Phiên bản tối đa, bao gồm
(,1.0)	x < 1,0	Phiên bản tối đa, độc quyền
[1.0,2.0]	1,0 ≤ x ≤ 2,0	Phạm vi chính xác, bao gồm
(1.0,2.0)	1,0 < x < 2,0	Phạm vi chính xác, độc quyền
[1.0,2.0)	1,0 ≤ x < 2,0	Phiên bản tối thiểu và tối đa dành riêng cho bao gồm hỗn hợp
(1.0)	không hợp lệ	không hợp lệ

NuGet cũng hỗ trợ sử dụng ký hiệu phiên bản trôi nổi cho các phần hậu tố chính, phụ, bản vá và tiền phát hành của số. Ký hiệu này là dấu sao (*). Ví dụ: thông số kỹ thuật phiên bản 6.0.* cho biết "sử dụng phiên bản 6.0.x mới nhất". Trong một ví dụ khác, 4.* có nghĩa là "sử dụng phiên bản 4.x mới nhất". Sử dụng phiên bản trôi nổi sẽ làm giảm các thay đổi đối với tệp dự án trong khi vẫn duy trì cập nhật với phiên bản phụ thuộc mới nhất.

Ghi

Chúng tôi khuyên bạn nên cài đặt một phiên bản cụ thể thay vì sử dụng bất kỳ ký hiệu nổi nào. Việc cài đặt một phiên bản cụ thể sẽ đảm bảo rằng các bản dựng của bạn có thể lặp lại trừ khi bạn yêu cầu rõ ràng một bản cập nhật phụ thuộc.

Khi bạn đang sử dụng phiên bản trôi nổi, NuGet sẽ giải quyết phiên bản mới nhất của gói khớp với mẫu phiên bản. Trong ví dụ sau đây, 6.0.* nhận được phiên bản mới nhất của gói bắt đầu với phiên bản 6.0. Phiên bản đó là 6.0.1.

Dưới đây là một số ví dụ có thể đặt cấu hình cho phiên bản chính, phụ hoặc bản vá:

<!-- Accepts any version 6.1 and later. -->
<PackageReference Include="ExamplePackage" Version="6.1" />

<!-- Accepts any 6.x.y version. -->
<PackageReference Include="ExamplePackage" Version="6.*" />
<PackageReference Include="ExamplePackage" Version="[6,7)" />

<!-- Accepts any later version, but not including 4.1.3. Could be
     used to guarantee a dependency with a specific bug fix. -->
<PackageReference Include="ExamplePackage" Version="(4.1.3,)" />

<!-- Accepts any version earlier than 5.x, which might be used to prevent pulling in a later
     version of a dependency that changed its interface. However, we don't recommend this form because determining the earliest version can be difficult. -->
<PackageReference Include="ExamplePackage" Version="(,5.0)" />

<!-- Accepts any 1.x or 2.x version, but not 0.x or 3.x and later. -->
<PackageReference Include="ExamplePackage" Version="[1,3)" />

<!-- Accepts 1.3.2 up to 1.4.x, but not 1.5 and later. -->
<PackageReference Include="ExamplePackage" Version="[1.3.2,1.5)" />

Tìm và cập nhật gói lỗi thời

Lệnh dotnet list package --outdated liệt kê các gói lỗi thời. Lệnh này có thể giúp bạn tìm hiểu khi nào các phiên bản gói mới hơn khả dụng. Đây là kết quả điển hình từ lệnh:

Top-level Package      Requested   Resolved   Latest
> Humanizer            2.7.*       2.7.9      2.8.26

Dưới đây là ý nghĩa của tên của các cột trong đầu ra:

• Requested: Phạm vi phiên bản hoặc phiên bản mà bạn đã xác định.
• Resolved: Phiên bản thực tế đã tải xuống cho dự án phù hợp với phiên bản được chỉ định.
• Latest: Phiên bản mới nhất có sẵn để cập nhật từ NuGet.

Dòng công việc được đề xuất là chạy các lệnh sau đây, theo thứ tự này:

1. Chạy dotnet list package --outdated. Lệnh này liệt kê tất cả các gói lỗi thời. Nó cung cấp thông tin trong Requested, Resolved, và Latest cột.
2. Chạy dotnet add package <package name>. Nếu bạn chạy lệnh này, nó sẽ cố gắng cập nhật lên phiên bản mới nhất. Hoặc bạn có thể chuyển vào --version=<version number/range>.