Mengelola pembaruan dependensi dalam proyek .NET Anda

  • 4 menit

Cepat atau lambat, Anda ingin memperbarui ke versi baru pustaka. Mungkin suatu fungsi ditandai sebagai tidak digunakan lagi, atau mungkin ada fitur baru di versi lebih baru dari paket yang Anda gunakan.

Pertimbangkan pertimbangan ini sebelum Anda mencoba memperbarui pustaka:

  • Jenis pembaruan: Jenis pembaruan apa yang tersedia? Apakah ini perbaikan bug kecil? Apakah perbaikan ini menambahkan fitur baru yang Anda butuhkan? Apakah itu melanggar kode Anda? Anda dapat mengomunikasikan jenis pembaruan dengan menggunakan sistem yang disebut penerapan versi semantik. Cara nomor versi pustaka dinyatakan berkomunikasi dengan pengembang jenis pembaruan yang mereka hadapi.
  • Apakah proyek dikonfigurasi dengan benar: Anda dapat mengonfigurasi proyek .NET sehingga Anda hanya mendapatkan jenis pembaruan yang Anda inginkan. Anda melakukan pembaruan hanya jika jenis pembaruan tertentu tersedia. Kami merekomendasikan pendekatan ini, karena Anda tidak mengambil risiko mengalami kejutan.
  • Masalah keamanan: Mengelola dependensi proyek Anda dari waktu ke waktu melibatkan mengetahui masalah yang mungkin terjadi. Masalah muncul karena terdeteksi kerentanan, misalnya. Idealnya, patch dirilis yang dapat Anda unduh. Alat .NET Core membantu Anda menjalankan audit di pustaka Anda untuk mengetahui apakah Anda memiliki paket yang harus diperbarui. Ini juga membantu Anda mengambil tindakan yang sesuai untuk memperbaiki masalah.

Menggunakan penerapan versi semantik

Ada standar industri yang disebut penerapan versi semantik, yaitu bagaimana Anda mengekspresikan jenis perubahan yang Anda atau beberapa pengembang lain perkenalkan ke pustaka. Pembuatan versi semantik bekerja dengan memastikan bahwa sebuah paket memiliki nomor versi, dan nomor versi dibagi menjadi beberapa bagian berikut:

  • Versi utama: Nomor paling kiri. Misalnya, itu 1 adalah di 1.0.0. Perubahan pada angka ini berarti Anda dapat mengharapkan "perubahan yang melanggar" dalam kode Anda. Anda mungkin perlu menulis ulang bagian dari kode Anda.
  • Versi minor: Nomor tengah. Misalnya, itu 2 adalah di 1.2.0. Perubahan pada angka ini berarti fitur ditambahkan. Kode Anda seharusnya masih berfungsi. Biasanya aman untuk menerima pembaruan.
  • Versi patch: Nomor paling kanan. Misalnya, itu 3 adalah di 1.2.3. Perubahan pada angka ini berarti bahwa perubahan diterapkan yang memperbaiki sesuatu dalam kode yang harus berfungsi. Seharusnya aman untuk menerima pembaruan.

Tabel ini menggambarkan bagaimana nomor versi berubah untuk setiap jenis versi:

Jenis Apa yang terjadi
Versi utama 1.0.0 perubahan ke 2.0.0
Versi minor 1.1.1 perubahan ke 1.2.0
Versi patch 1.0.1 perubahan ke 1.0.2

Banyak perusahaan dan pengembang menggunakan sistem ini. Jika Anda ingin menerbitkan paket dan mendorongnya ke registri NuGet, Anda diharapkan untuk mengikuti penerapan versi semantik. Bahkan jika Anda hanya mengunduh paket dari registri NuGet, Anda dapat mengharapkan paket ini mengikuti penerapan versi semantik.

Perubahan pada paket dapat menimbulkan risiko, termasuk risiko bahwa bug dapat membahayakan bisnis Anda. Beberapa risiko mungkin mengharuskan Anda menulis ulang bagian dari kode. Menulis ulang kode membutuhkan waktu dan biaya.

Pendekatan pembaruan

Sebagai pengembang .NET, Anda dapat mengomunikasikan perilaku pembaruan yang Ingin Anda .NET. Pikirkan tentang memperbarui dalam hal risiko. Berikut adalah beberapa pendekatan:

  • Versi utama: Saya setuju untuk memperbarui ke versi utama terbaru segera setelah dirilis. Saya menerima kenyataan bahwa saya mungkin perlu mengubah kode di pihak saya.
  • Versi minor: Saya SENANG dengan fitur baru yang ditambahkan. Saya bermasalah dengan kode yang rusak.
  • Versi patch: Satu-satunya pembaruan yang saya ok dengan adalah perbaikan bug.

Jika Anda mengelola proyek .NET baru atau yang lebih kecil, Anda dapat lebih longgar dengan cara Anda menentukan strategi pembaruan. Misalnya, Anda selalu dapat memperbarui ke versi terbaru. Untuk proyek yang lebih kompleks, ada lebih banyak nuansa, tetapi kita akan menyimpannya untuk modul di masa mendatang.

Secara umum, semakin kecil dependensi yang Anda perbarui, semakin sedikit dependensi yang dimilikinya dan semakin besar kemungkinan proses pembaruannya mudah.

Mengonfigurasi file proyek untuk pembaruan

Saat Anda menambahkan satu atau beberapa dependensi, konfigurasikan file proyek sehingga Anda mendapatkan perilaku yang dapat diprediksi saat memulihkan, membangun, atau menjalankan proyek Anda. Anda dapat mengomunikasikan pendekatan yang ingin Anda ambil untuk sebuah paket. NuGet memiliki konsep rentang versi dan versi mengambang.

Rentang versi adalah notasi khusus yang dapat Anda gunakan untuk menunjukkan rentang versi tertentu yang ingin Anda atasi.

Notasi Aturan yang diterapkan Deskripsi
1.0 x >= 1,0 Versi minimum, inklusif
(1.0,) x > 1.0 Versi minimum, eksklusif
[1.0] x == 1.0 Kecocokan versi yang tepat
(,1.0] x ≤ 1.0 Versi maksimum, inklusif
(,1.0) x < 1.0 Versi maksimum, eksklusif
[1.0,2.0] 1.0 ≤ x ≤ 2.0 Rentang yang tepat, inklusif
(1.0,2.0) 1.0 < x < 2.0 Rentang yang tepat, eksklusif
[1.0,2.0) 1.0 ≤ x < 2.0 Versi campuran minimum inklusif dan maksimum eksklusif
(1.0) tak sahih tak sahih

NuGet juga mendukung penggunaan notasi versi mengambang untuk bagian akhiran utama, minor, patch, dan prarilis dari angka tersebut. Notasi ini adalah tanda bintang (*). Misalnya, spesifikasi versi 6.0.* mengatakan "gunakan versi 6.0.x terbaru." Dalam contoh lain, 4.* berarti "gunakan versi 4.x terbaru." Menggunakan versi mengambang mengurangi perubahan pada file proyek sambil tetap mendapatkan informasi terbaru tentang versi dependensi terbaru.

Catatan

Sebaiknya instal versi tertentu alih-alih menggunakan salah satu notasi float. Menginstal versi tertentu memastikan bahwa build dapat diulang kecuali secara eksplisit meminta pembaruan ke dependensi.

Saat Anda menggunakan versi mengambang, NuGet menyelesaikan versi terbaru dari paket yang cocok dengan pola versi. Dalam contoh berikut, 6.0.* mendapatkan versi terbaru dari paket yang dimulai dengan 6.0. Versi itu adalah 6.0.1.

Diagram memperlihatkan memilih versi terbaru saat versi mengambang diminta.

Berikut adalah beberapa contoh yang dapat dikonfigurasi untuk versi utama, minor, atau patch:

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

Menemukan dan memperbarui paket yang sudah kedaluarsa

Perintah dotnet list package --outdated mencantumkan paket yang sudah kedaluarsa. Perintah ini dapat membantu Anda mempelajari kapan versi paket yang lebih baru tersedia. Berikut adalah output khas dari perintah:

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

Berikut adalah arti dari nama-nama kolom di output:

  • Requested: Rentang versi atau versi yang Anda tentukan.
  • Resolved: Versi aktual yang diunduh untuk proyek yang cocok dengan versi yang ditentukan.
  • Latest: Versi terbaru yang tersedia untuk pembaruan dari NuGet.

Alur kerja yang disarankan adalah menjalankan perintah berikut, dalam urutan ini:

  1. Jalankan dotnet list package --outdated. Perintah ini mencantumkan semua paket yang telah kedaluarsa. Ini memberikan informasi di kolom Requested, Resolved, dan Latest.
  2. Jalankan dotnet add package <package name>. Jika Anda menjalankan perintah ini, perintah ini mencoba memperbarui ke versi terbaru. Secara opsional, Anda juga dapat meneruskan --version=<version number/range>.