เราควรรวมโฟลเดอร์ Nuget PACKAGE ไว้ในการควบคุมเวอร์ชันหรือไม่?


68

ผมอยากจะรู้ว่า

ในโครงการ C # หรือ VB.NET เราควรรวมโฟลเดอร์ PACKAGE (โฟลเดอร์แพคเกจ nugget ที่สร้างขึ้นเพื่อรูทของโครงการของฉันที่มีไฟล์ nupkg และเนื้อหาอื่น ๆ ) ไปยังแหล่งเก็บข้อมูลแหล่งควบคุม (Git เป็นต้น)


ใช่แน่นอนเพราะไฟล์เหล่านี้เป็นส่วนหนึ่งของรหัสและโครงการของคุณจะไม่สร้างขึ้นหากไม่มีไฟล์เหล่านั้น
Sharky

ฉันถามคำถามที่คล้ายกันเกี่ยวกับ SO ตลอดเวลาที่ผ่านมา คุณสามารถดูคำตอบได้ที่นี่: stackoverflow.com/questions/1710027/… :)
cwap

ฉันสงสัยว่าทำไมไม่มีใครในโลก Maven ถามว่า "เราควรรวม libs ของบุคคลที่สามในการควบคุมเวอร์ชัน" ค้นหาข้อโต้แย้งที่มั่นคงสำหรับการไม่ยอมรับ libs แต่ไม่น่าเชื่อถือมาก
Hoàng Long

คำตอบ:


28

เวลาผ่านไปนานมากแล้ว NuGet ก็เปลี่ยนไปดังนั้นนี่เป็นคำตอบใหม่

NuGet ไม่สร้างโฟลเดอร์แพ็คเกจภายในโครงสร้างแหล่งที่มาของคุณอีกต่อไป แต่มีหนึ่งในไดเรกทอรีผู้ใช้ของคุณ ( %HOME%\.nuget\packagesเฉพาะเจาะจง) ซึ่งมันทำให้แพ็คเกจทั้งหมดที่ดาวน์โหลดและโครงการเพียงแค่อ้างอิงสิ่งเหล่านี้

ดังนั้นคำตอบง่ายๆในวันนี้คือไม่คุณไม่ควรทำ หากคุณกังวลเกี่ยวกับแพ็คเกจที่คุณต้องหายไปคุณควรสร้างกระจกเงา NuGet ในพื้นที่ที่คุณสำรองข้อมูลแยกต่างหาก


6
ฉันใช้ VS2015 (พิจารณาว่า VS2017 เปิดตัวเพียง 3 วันก่อนที่คุณจะเขียนคำตอบนี้) และโฟลเดอร์แพ็คเกจมีอยู่ในรูทโซลูชันของฉัน ฉันอยากรู้ว่า NuGet เปลี่ยนแปลงอย่างไรและเมื่อไหร่
Teejay

NuGet เปลี่ยนไปเป็นเวอร์ชั่น 3 ซึ่งได้รับการปล่อยตัวออกมาจากวงในช่วงเวลา VS2015
Sebastian Redl

ฉันเพิ่งตรวจสอบบนคอมพิวเตอร์ที่ทำงานของฉันและแพคเกจที่คุณพูด แต่ในคอมพิวเตอร์ที่บ้านของฉันพวกเขาอยู่ในไดเรกทอรีโครงการ ทั้งสองอยู่ใน VS2015 (professional @ work, community @ home) และ home one เป็นการติดตั้งล่าสุดมาก ... มันแปลก
Teejay

12
เพิ่งติดตั้ง VS 2017 เมื่อสัปดาห์ที่แล้วสร้างโครงการใหม่เมื่อวานนี้และมีไดเรกทอรีแพ็คเกจในโครงการของฉัน
Jeremy

2
คุณทำอะไรให้ CI คุณทำให้มันดาวน์โหลดแพ็คเกจ nuget ทั้งหมดซ้ำแล้วซ้ำอีก? (TBH: ฉันตัวฉันเองไม่ชัดเจนว่าความคิดเห็นของฉันคืออะไร)
Tomer W

50

มันขึ้นอยู่กับ.

ลองดูคำตอบของ Bart van Ingen Schenauเพื่อตรวจสอบว่าเป็นไปได้ไหมที่จะไม่สนใจpackagesโฟลเดอร์เลย

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

แต่คุณไม่ควรสนใจมัน? ฉันพูดว่า: มันขึ้นอยู่กับ
IMO เป็นคำถามที่ว่า "เราสามารถทำงานต่อได้ในกรณีที่ที่เก็บแพ็กเกจไม่พร้อมใช้งาน" (ไม่ว่าจะเป็นการชั่วคราวหรือถาวร)

สำหรับโครงการ OSS ส่วนบุคคลของฉันฉันมีpackagesโฟลเดอร์ที่ละเว้นในทุกโครงการ
เมื่อ nuget.org ออฟไลน์ฉันจะรอและดำเนินการอีกวัน

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

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


1
nuget.org ใช้งานไม่ได้บ่อยแค่ไหน
Bartosz

4
อาจไม่บ่อยมาก แต่บางทีฉันควรจะพูดว่า "ไม่สามารถเข้าถึงได้" แทนที่จะเป็น "ออฟไลน์" เมื่อไม่กี่ปีที่ผ่านมาเรามีเหตุการณ์ที่เกิดขึ้นในที่ทำงานซึ่งนักขุดตัดสายเคเบิลอินเทอร์เน็ตไปยังอาคารของเราโดยไม่ตั้งใจ ใช้เวลามากกว่าหนึ่งวันในการซ่อมแซม หากเราพึ่งพา nuget.org เราจะไม่สามารถสร้างโครงการของเราได้ (ใช่ฉันรู้แล้วทุกวันนี้ NuGet แคชแพ็กเกจไว้ในเครื่อง ... แต่ไม่ใช่ตอนนี้)
Christian Specht

ฉันจะบอกว่าเวลาสร้างจะนานขึ้นเมื่อคุณไม่ได้ตรวจสอบในโฟลเดอร์แพ็กเกจเพราะมันใช้เวลาส่วนใหญ่ในการเรียกค้นแพ็คเกจในระหว่างการคืนค่าแพ็คเกจ
AaronLS

29

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

กล่าวอีกนัยหนึ่งถ้าคุณสามารถทิ้งโฟลเดอร์ PACKAGE และเนื้อหาโดยไม่ส่งผลกระทบต่อความสามารถในการทำงานของโครงการต่อไป (บิลด์อาจใช้เวลานานกว่า แต่คุณไม่ต้องตามล่าและติดตั้งอะไรเอง) จากนั้นโฟลเดอร์สามารถ ออกจากที่เก็บอย่างปลอดภัย
หากโฟลเดอร์มีแพ็กเกจภายนอกที่อาจใช้เวลานานในการดาวน์โหลดหรืออาจไม่สามารถใช้งานได้นั่นอาจเป็นสาเหตุที่เพิ่มให้กับที่เก็บของคุณ


20
ฉันจะเพิ่มว่าคุณควรเก็บรุ่นของรหัสของบุคคลที่สามใด ๆ ที่ใช้ในโครงการที่เก็บไว้อย่างปลอดภัยในกรณีที่โครงการของบุคคลที่สามถูกลบออกไซต์ที่โฮสต์มันหายไป ฯลฯ เป็นสถานที่ที่ดีในการทำเช่นนั้น . สิ่งนี้ยังเปิดโอกาสให้คุณย้อนกลับไปยังโค้ดรุ่นก่อนหน้าหากจำเป็น
Bent
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.