จัดการการปรับปรุงการขึ้นต่อกันในโครงการ .NET ของคุณ

  • 4 นาที

ไม่ช้าก็เร็ว คุณต้องการอัปเดตเป็นไลบรารีเวอร์ชันใหม่ บางทีฟังก์ชันถูกทําเครื่องหมายว่าเลิกใช้แล้ว หรืออาจมีคุณลักษณะใหม่ในแพคเกจเวอร์ชันที่ใหม่กว่าที่คุณกําลังใช้อยู่

คํานึงถึงข้อควรพิจารณาเหล่านี้ก่อนที่คุณจะพยายามอัปเดตไลบรารี:

  • การอัปเดตประเภทใด : มีการอัปเดตชนิดใดที่พร้อมใช้งาน มันเป็นการแก้ไขข้อบกพร่องขนาดเล็กหรือไม่? กําลังเพิ่มคุณลักษณะใหม่ที่คุณต้องการหรือไม่ มันทําลายรหัสของคุณหรือไม่? คุณสามารถสื่อสารชนิดของการอัปเดตโดยใช้ระบบที่เรียกว่า การกําหนดรุ่นเชิงความหมาย วิธีการแสดงหมายเลขเวอร์ชันของไลบรารีติดต่อสื่อสารกับนักพัฒนาถึงประเภทของการอัปเดตที่พวกเขาจัดการ
  • ว่าโครงการได้รับการกําหนดค่าอย่างถูกต้องหรือไม่ : คุณสามารถกําหนดค่าโครงการ .NET ของคุณเพื่อให้คุณได้รับเฉพาะชนิดการอัปเดตที่คุณต้องการเท่านั้น คุณทําการอัปเดตเมื่อชนิดเฉพาะของการอัปเดตพร้อมใช้งานเท่านั้น เราขอแนะนําวิธีนี้เนื่องจากคุณไม่มีความเสี่ยงที่จะเกิดเรื่องประหลาดใจ
  • ปัญหาด้านความปลอดภัย: การจัดการการขึ้นต่อกันของโครงการของคุณเมื่อเวลาผ่านไป เกี่ยวข้องกับการตระหนักถึงปัญหาที่อาจเกิดขึ้น ปัญหาเกิดขึ้นเมื่อมีการตรวจพบช่องโหว่ ตามแนวคิดแล้วแพทช์จะถูกเผยแพร่ที่คุณสามารถดาวน์โหลดได้ เครื่องมือ .NET Core ช่วยให้คุณเรียกใช้การตรวจสอบ ไลบรารีของคุณเพื่อค้นหาว่าคุณมีแพคเกจที่ควรได้รับการอัปเดตหรือไม่ นอกจากนี้ยังช่วยให้คุณดําเนินการที่เหมาะสมเพื่อแก้ไขปัญหา

ใช้การกําหนดรุ่นเชิงความหมาย

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

  • เวอร์ชันหลัก: จํานวนซ้ายสุด ตัวอย่างเช่น เป็น 1 ใน 1.0.0 การเปลี่ยนแปลงหมายเลขนี้หมายความว่าคุณสามารถคาดหวัง "การเปลี่ยนแปลงที่เสียหาย" ในรหัสของคุณ คุณอาจต้องเขียนโค้ดของคุณอีกครั้ง
  • เวอร์ชันรอง: หมายเลขกลาง ตัวอย่างเช่น เป็น 2 ใน 1.2.0 การเปลี่ยนแปลงตัวเลขนี้หมายความว่ามีการเพิ่มคุณลักษณะ รหัสของคุณควรยังคงทํางานได้ โดยทั่วไปแล้วจะปลอดภัยในการยอมรับการอัปเดต
  • เวอร์ชัน Patch: จํานวนขวาสุด ตัวอย่างเช่น เป็น 3 ใน 1.2.3 การเปลี่ยนแปลงหมายเลขนี้หมายความว่ามีการใช้การเปลี่ยนแปลงที่แก้ไขบางอย่างในโค้ดที่ควรทํางาน ควรปลอดภัยในการยอมรับการอัปเดต

ตารางนี้แสดงให้เห็นว่าหมายเลขเวอร์ชันสําหรับเวอร์ชันแต่ละชนิดมีการเปลี่ยนแปลงอย่างไร:

ประเภท จะเกิดอะไรขึ้น
เวอร์ชันหลัก 1.0.0 การเปลี่ยนแปลงไปยัง 2.0.0
เวอร์ชันรอง 1.1.1 การเปลี่ยนแปลงไปยัง 1.2.0
เวอร์ชันโปรแกรมแก้ไข 1.0.1 การเปลี่ยนแปลงไปยัง 1.0.2

บริษัทและนักพัฒนาจํานวนมากใช้ระบบนี้ ถ้าคุณต้องการเผยแพร่แพคเกจและส่งไปยังรีจิสทรี NuGet คุณคาดว่าจะทําตามการกําหนดรุ่นความหมาย แม้ว่าคุณจะดาวน์โหลดแพคเกจจากรีจิสทรี NuGet เท่านั้น คุณสามารถคาดหวังให้แพคเกจเหล่านี้ทําตามการกําหนดรุ่นความหมาย

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

อัปเดตวิธีการ

ในฐานะนักพัฒนา .NET คุณสามารถสื่อสารถึงลักษณะการทํางานการอัปเดตที่คุณต้องการ .NET ได้ คิดเกี่ยวกับการอัปเดตในแง่ของความเสี่ยง ต่อไปนี้คือวิธีการบางอย่าง:

  • เวอร์ชันหลัก: ฉันโอเคกับการอัปเดตเป็นเวอร์ชันหลักล่าสุดทันทีที่มี ฉันยอมรับความจริงที่ว่าฉันอาจจําเป็นต้องเปลี่ยนรหัสในตอนท้ายของฉัน
  • เวอร์ชันรอง: ฉันโอเคกับคุณลักษณะใหม่ที่ถูกเพิ่ม ฉันไม่โอเคกับรหัสที่เสียหายนั้น
  • เวอร์ชัน Patch: การอัปเดตเดียวที่ฉันสามารถใช้ได้คือ การแก้ไขข้อบกพร่อง

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

โดยทั่วไป การขึ้นต่อกันที่คุณกําลังอัปเดตมีขนาดเล็กลง การขึ้นต่อกันที่มีน้อยลงและมีโอกาสมากที่กระบวนการอัปเดตจะเป็นเรื่องง่าย

กําหนดค่าไฟล์โครงการสําหรับการอัปเดต

เมื่อคุณกําลังเพิ่มการขึ้นต่อกันอย่างน้อยหนึ่งรายการ ให้กําหนดค่าไฟล์โครงการของคุณเพื่อให้คุณได้รับลักษณะการทํางานที่คาดการณ์ได้เมื่อคุณคืนค่า สร้าง หรือเรียกใช้โครงการของคุณ คุณสามารถสื่อสารวิธีการที่คุณต้องการใช้สําหรับแพคเกจได้ NuGet มีแนวคิดของช่วง เวอร์ชัน และเวอร์ชันลอยตัว

ช่วงเวอร์ชันเป็นสัญลักษณ์พิเศษที่คุณสามารถใช้เพื่อระบุช่วงเฉพาะของเวอร์ชันที่คุณต้องการแก้ไข

เครื่องหมาย กฎที่นําไปใช้ คำอธิบาย
1.0 x >= 1.0 เวอร์ชันขั้นต่ํา แบบครอบคลุม
(1.0,) x > 1.0 เวอร์ชันขั้นต่ําสุดแบบไม่จํากัด
[1.0] x == 1.0 เวอร์ชันที่ตรงกันทุกประการ
(,1.0] x ≤ 1.0 เวอร์ชันสูงสุด แบบครอบคลุม
(,1.0) x < 1.0 เวอร์ชันสูงสุด แบบไม่รวม
[1.0,2.0] 1.0 ≤ x ≤ 2.0 ช่วงที่แน่นอน, แบบครอบคลุม
(1.0,2.0) 1.0 < x 2.0 < ช่วงที่แน่นอน ไม่รวม
[1.0,2.0) 1.0 ≤ x < 2.0 เวอร์ชันต่ําสุดและเวอร์ชันสูงสุดรวมแบบผสม
(1.0) ไม่ถูกต้อง ไม่ถูกต้อง

NuGet ยังสนับสนุนการใช้สัญกรณ์เวอร์ชันลอยสําหรับส่วนต่อท้ายตัวเลขหลัก รอง โปรแกรมแก้ไข และส่วนต่อท้ายที่เผยแพร่ล่วงหน้าของตัวเลข เครื่องหมายนี้เป็นเครื่องหมายดอกจัน (*) ตัวอย่างเช่น ข้อกําหนดเวอร์ชัน 6.0.* ระบุว่า "ใช้เวอร์ชัน 6.0.x ล่าสุด" ในตัวอย่างอื่น 4.* หมายถึง "ใช้เวอร์ชัน 4.x ล่าสุด" การใช้เวอร์ชันลอยตัวจะลดการเปลี่ยนแปลงไปยังไฟล์โครงการในขณะที่ยังคงอัปเดตอยู่เสมอด้วยเวอร์ชันล่าสุดของการขึ้นต่อกัน

โน้ต

เราขอแนะนําให้ติดตั้งเวอร์ชันเฉพาะแทนการใช้เครื่องหมายเลขทศนิยมใด ๆ การติดตั้งเวอร์ชันเฉพาะช่วยให้มั่นใจได้ว่ารุ่นของคุณจะสามารถทําซ้ําได้เว้นแต่คุณจะร้องขอการอัปเดตให้มีการขึ้นต่อกันอย่างชัดเจน

เมื่อคุณใช้เวอร์ชันลอย NuGet จะแก้ไขแพ็คเกจเวอร์ชันล่าสุดที่ตรงกับรูปแบบเวอร์ชัน ในตัวอย่างต่อไปนี้ 6.0. * ได้รับแพคเกจเวอร์ชันล่าสุดที่เริ่มต้นด้วย 6.0 เวอร์ชันดังกล่าวคือ 6.0.1

แผนภาพที่แสดงการเลือกเวอร์ชันล่าสุดเมื่อมีการร้องขอเวอร์ชันลอยตัว

นี่คือตัวอย่างบางส่วนที่สามารถกําหนดค่าสําหรับเวอร์ชันหลัก รอง หรือโปรแกรมแก้ไข:

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

ค้นหาและอัปเดตแพคเกจที่ล้าสมัย

คําสั่ง dotnet list package --outdated แสดงรายการแพคเกจที่ล้าสมัย คําสั่งนี้สามารถช่วยให้คุณเรียนรู้เมื่อมีแพคเกจเวอร์ชันที่ใหม่กว่าพร้อมใช้งาน นี่คือผลลัพธ์ทั่วไปจากคําสั่ง:

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

นี่คือความหมายของชื่อของคอลัมน์ในผลลัพธ์:

  • Requested: เวอร์ชันหรือช่วงเวอร์ชันที่คุณระบุ
  • Resolved: เวอร์ชันจริงที่ดาวน์โหลดสําหรับโครงการที่ตรงกับเวอร์ชันที่ระบุ
  • Latest: เวอร์ชันล่าสุดพร้อมใช้งานสําหรับการอัปเดตจาก NuGet

เวิร์กโฟลว์ที่แนะนําคือการเรียกใช้คําสั่งต่อไปนี้ตามลําดับ:

  1. เรียกใช้ dotnet list package --outdated คําสั่งนี้แสดงรายการแพคเกจที่ล้าสมัยทั้งหมด ซึ่งจะให้ข้อมูลในคอลัมน์ Requested, Resolved, และ Latest
  2. เรียกใช้ dotnet add package <package name> ถ้าคุณเรียกใช้คําสั่งนี้ โปรแกรมจะพยายามอัปเดตเป็นเวอร์ชันล่าสุด อีกทางหนึ่งคือ คุณสามารถส่งผ่าน --version=<version number/range>ได้