ตรวจสอบแพ็คเกจจาก NuGet ในการควบคุมเวอร์ชันหรือไม่


87

ก่อนหน้า NuGet เป็นที่ยอมรับกันทั่วไปว่า 'แนวทางปฏิบัติที่ดีที่สุด' ในการเช็คอิน DLL ภายนอกทั้งหมดที่ใช้ในโครงการ โดยปกติจะอยู่ในไดเรกทอรีLibsหรือ3rdParty

เมื่อทำงานกับ NuGet ฉันควรเช็คอินpackagesไดเร็กทอรีหรือมีวิธีให้ MSBuild ดาวน์โหลดแพ็กเกจที่ต้องการจากฟีดนักเก็ตโดยอัตโนมัติหรือไม่


2
คำตอบสำหรับเรื่องนี้เป็นเรื่องของความคิดเห็น ค่าย "ไม่รวม / ไม่" จะคงไว้เนื่องจากชุดคุณลักษณะที่ให้มาทำให้ง่ายในระหว่างการพัฒนาและสร้างเพียงแค่ดึงจากที่เก็บแพ็กเกจ (เช่น nuget.org) ก็สามารถทำได้ในเวลาสร้าง ค่าย "รวม / ใช่" ยืนยันว่ารหัสจะไม่สร้างโดยไม่มีแพ็กเกจหากที่เก็บภายนอกไม่สามารถใช้งานได้ อ่านทั้งสองด้านก่อนตัดสินใจ ดูเพิ่มเติมที่: softwareengineering.stackexchange.com/questions/301547/…
CJBS

คำตอบ:


68

ไม่

เนื่องจากคำถามนี้ถูกถามตอนนี้จึงมีขั้นตอนการทำงานที่ง่ายในการใช้ NuGet โดยไม่ต้องใช้แพ็คเกจเพื่อควบคุมแหล่งที่มา

จากคอนโซลตัวจัดการแพ็คเกจคุณต้องติดตั้ง'NuGetPowerTools' :

Install-Package NuGetPowerTools

จากนั้นเพื่อเปิดใช้งานโครงการของคุณเพื่อรองรับการคืนค่าแพ็คคุณต้องเรียกใช้คำสั่งอื่น:

Enable-PackageRestore

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

ที่มา

การใช้ NuGet โดยไม่ต้องเชื่อมต่อแพ็คเกจกับการควบคุมแหล่งที่มา


41
ตั้งแต่ NuGet-1.6 คุณไม่จำเป็นต้องใช้ NuGetPowerTools ในการทำสิ่งนี้อีกต่อไป เพียงแค่คลิกขวาที่โซลูชั่นในโซลูชัน Explorer Enable NuGet Package Restoreและเลือก ดูเอกสาร
Kaleb Pederson

3
ใช่คุณต้องตรวจสอบในโฟลเดอร์. net และไฟล์ที่อยู่ข้างใต้
absynce

11
@Edward - ตามหลักปรัชญาทำไมคุณไม่รวมแพ็คเกจ NuGet ในการควบคุมแหล่งที่มาเนื่องจากว่าเป็นการอ้างอิง สิ่งที่ตรวจสอบในการควบคุมแหล่งที่มาควรเป็น 100% ของรหัสที่เพียงพอสำหรับการสร้าง โดยไม่รวมแพ็คเกจ NuGet จะมีการสร้างการอ้างอิงภายนอกเช่น จะเกิดอะไรขึ้นหากตำแหน่งการดาวน์โหลดแพ็กเกจมีการเปลี่ยนแปลงหรือด้วยเหตุผลแปลก ๆ ทำให้ไม่สามารถใช้งานได้อีกต่อไป ฯลฯ หรือมีแนวโน้มว่าจะเกิดอะไรขึ้นหากมีการเปลี่ยนแปลงเล็กน้อยในแพ็กเกจที่ดาวน์โหลดใหม่ในภายหลังและทำให้บิวด์เสียหาย สิ่งนี้จะหลีกเลี่ยงได้หากทุกสิ่งที่จำเป็นในการสร้างโครงการอยู่ในการควบคุมแหล่งที่มา
Howiecamp

5
@ Howiecamp ฉันไม่เห็นด้วยมากกว่านี้ ฉันไม่เข้าใจตรรกะ ฉันต้องการให้การควบคุมแหล่งที่มาเป็นระบบที่มีอยู่ในตัวเองทั้งหมด โดยเฉพาะอย่างยิ่งหากโครงการเป็นแบบเดิมและไม่มีการเข้าถึงสักระยะหนึ่ง ฉันต้องการกลับมาและทำให้มันทำงานได้โดยไม่มีการปรับเปลี่ยน Nuget เป็นจุดเดียวของความล้มเหลวที่ฉันไม่ต้องการมี
Telavian

2
@Howiecamp วิธีแก้ปัญหาของเราคือโฮสต์เซิร์ฟเวอร์ nuget ของเราเองและใส่แพ็คเกจ nuget ทั้งหมดภายในเป็นภายนอกลงใน GIT-LFS สิ่งนี้จะลบจุดเดียวของความล้มเหลวและช่วยให้ทุกอย่างอยู่ภายใต้การควบคุมเวอร์ชัน แต่เรายังไม่ได้ตรวจสอบในโฟลเดอร์แพ็คเกจ - และเรายังคงใช้การคืนค่าแพ็คเกจอัตโนมัติ
Casper Leon Nielsen

30

ใช่. พิจารณาว่าไดเร็กทอรี "แพ็กเกจ" เทียบเท่ากับไดเร็กทอรี "libs" ที่คุณกล่าวถึงในคำถามของคุณ นี่เป็นแนวทางที่ฉันใช้กับโครงการ OSS ของฉันเป็นการส่วนตัว

เรากำลังตรวจสอบคุณสมบัติที่อนุญาตให้ MSBuild ดาวน์โหลดแพ็กเกจที่ต้องการโดยอัตโนมัติ แต่ยังไม่ได้ใช้ (ณ NuGet 1.1)

ฉันคิดว่าบางคนอาจติดตั้งฟีเจอร์ดังกล่าวด้วยตัวเองแล้ว แต่แผนของเราคือการมองไปที่การมีฟีเจอร์นั้นใน NuGet 1.2 หรือ 1.3 หวังว่า


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

2
หากผู้จัดการแพ็กเกจใน Visual Studio และเครื่องมือบรรทัดคำสั่งสามารถ "ซ่อมแซมแพ็กเกจ" ได้ซึ่งก็น่าจะดี
Shaun Wilson

1
บางทีอาจเป็นการดีที่จะลบ / แก้ไขคำตอบนี้ตอนนี้มันล้าสมัย
Lex

3
@ Tim answer ไม่ใช่ imho ปัจจุบัน
Edward Wilde

4
คำตอบนี้ยังคงเป็นปัจจุบัน พิจารณาแพ็คเกจที่ไม่ได้อยู่ในที่เก็บส่วนกลาง (ไม่มีวิธีซ่อมแซม / ดาวน์โหลด) IMHO เป็นแนวทางปฏิบัติที่ดีในการจัดเก็บแพ็คเกจในระบบกำหนดเวอร์ชัน
Pavel Hodek

6

แม้จะมีคำตอบทั้งหมดที่นี่ แต่ก็ยังคงเป็นทางออกที่น่าสยดสยองธรรมดาที่จะไม่มีการอ้างอิงทั้งหมดของคุณภายใต้การควบคุมเวอร์ชัน "บางประเภท"

สำหรับ GIT นี่จะหมายถึง GIT-LFS

ตอนล่าสุดที่มี NPM แสดงให้เห็นว่าทำไม: หากที่เก็บข้อมูลอินเทอร์เน็ตที่คุณใช้งานอยู่ไม่สามารถใช้งานได้ ฯลฯ แสดงว่าคุณเมาแล้วใช่ไหม

คุณไม่สามารถสร้างสิ่งของของคุณได้อีกต่อไป - ดังนั้นจึงไม่สามารถส่งมอบได้


1
นี่เป็นจุดที่ดีมาก แม้ว่าเราจะมีเซิร์ฟเวอร์ NuGet ภายในของเราเอง แต่เราสามารถพึ่งพาเซิร์ฟเวอร์นี้ให้พร้อมใช้งานได้ตลอดเวลาหรือไม่? นอกจากนี้แพ็คเกจของเรามีการเปลี่ยนแปลงบ่อยเพียงใดที่เราจำเป็นต้องได้รับสำเนาใหม่สำหรับทุกงานสร้างเสมอ
Josh P

npmพังเพราะไม่ได้ยกเลิกการแสดงแพ็กเกจมันลบออกไปจริงๆ NuGet ไม่ทำเช่นนี้ หากเมื่อใดก็ตามที่คุณไม่สามารถเข้าถึง NuGet มีบางอย่างผิดปกติอย่างมาก ฉันไม่คิดว่าการจัดเก็บข้อมูลอ้างอิงใน git เป็นวิธีแก้ปัญหาที่ดีเพียงแค่ล็อคการอ้างอิงของคุณไปยังเวอร์ชันที่เฉพาะเจาะจงและมีกระจกกั้นระหว่างคุณและในอินเทอร์เน็ตหากสิ่งนั้นสำคัญกับคุณ
แดน

2
"NuGet ไม่ทำเช่นนี้" คุณเพิ่งทำสัญญากับอนาคตของโดเมนที่อยู่เหนือการควบคุมของคุณ ในโลกแห่งความเป็นจริงสิ่งต่าง ๆ ที่อยู่นอกเหนือการควบคุมของคุณสิ่งเหล่านี้ก็อยู่นอกเหนือการควบคุมของคุณ สิ่งนี้ใช้กับ NuGet และ Npm นอกจากนี้แนวคิดของคุณเกี่ยวกับ "กระจกเงา" คือสิ่งที่ฉันเสนอไว้ที่นี่ แต่ในโลกของคุณ "กระจก" ไม่ได้รับการสนับสนุนจากรูปแบบการควบคุมเวอร์ชันใด ๆ อีกครั้งคุณยังไม่ได้แก้ปัญหาที่คุณกำหนดไว้
Casper Leon Nielsen

5

ตั้งแต่ถามคำถามฉันได้วางแนวทางต่อไปนี้เพื่อที่ฉันจะได้ไม่ต้องเช็คอิน toplovel Packagesไดเรกทอรี

ในไฟล์ toplevel build.msbuild:

<Target Name="NuGet">
    <ItemGroup>
       <NuGetPackage Include="*\packages.config" />
    </ItemGroup>
    <Exec Command='libs\NuGet.exe install "%(NuGetPackage.FullPath)" -o Packages'  />

    <!-- optional for project that has JavaScript content -->
    <CreateItem Include="Packages\*\Content\Scripts\*">
       <Output TaskParameter="Include" ItemName="NuGetJSFiles"/>
    </CreateItem>
    <Copy SourceFiles="@(NuGetJSFiles)" DestinationFolder="MainProj\Scripts\" OverwriteReadOnlyFiles="true" SkipUnchngedFiles="true" />
    <Delete Files="MainProj\Scripts\.gitignore" />
    <WriteLinesToFile File="MainProj\Scripts\.gitignore" Lines="%(NuGetJSFiles.Filename)%(NuGetJSFiles.Extension)" /
    <Delete Files="@(PostNuGetFiles)" />
</Target>

ในแต่ละไฟล์ project.csproj

<Target Name="BeforeBuild">
    <Error Condition="!Exists('..\Packages\')" Text="You must run &gt; msbuild build.msbuild to download required NuGet
Packages" />

    <!-- optional for project that has JavaScript content -->
   <ReadLinesFromFile File="Scripts\.gitignore">
     <Output TaskParameter="Lines" ItemName="ReqJSFiles" />
   </ReadLinesFromFile>
   <Message Text="@(ReqJSFiles)" />
   <Error Condition="!Exists('Scripts\%(ReqJSFiles.Identity)')" Text="You must run &gt; msbuild build.msbuild to download required NuGet JS Package - Scripts\%(ReqJSFiles.Identity)" />
 </Target>

2
วิธีนี้ใช้งานได้ แต่วันนี้ดีที่สุดเพียงแค่ใช้การเปิดใช้งานการกู้คืนแพ็คเกจในตัว
Scott Weinstein

4

ฉันตระหนักดีว่าความจริงนั้นแตกต่างออกไปเมื่อมีการโพสต์และตอบคำถามนี้ แต่โชคดีที่คำตอบเปลี่ยนไปเล็กน้อย ตอนนี้สามารถใช้ NuGet เพื่อดาวน์โหลดการอ้างอิงผ่าน MSBuild โดยใช้เหตุการณ์ Pre-Build คุณไม่จำเป็นต้องใส่โฟลเดอร์แพ็กเกจในที่เก็บโค้ดของคุณการอ้างอิงทั้งหมดจะถูกดาวน์โหลดและ / หรืออัปเดตในบิลด์ อาจเป็นวิธีแก้ปัญหา แต่ก็ดูดีพอ ดูรายละเอียดในบล็อกโพสต์ต่อไปนี้: http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html


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

3

ณ วันที่ 09/20/56 มีสิ่งที่เรียกว่า "Nuget Restore" คุณไม่จำเป็นต้องเช็คอินโฟลเดอร์แพ็คเกจหากต้องการทำเช่นนั้น (โดยเฉพาะอย่างยิ่งถ้าคุณใช้ DVCS)

ตรวจสอบสิ่งนี้: การใช้ NuGet โดยไม่ต้องใช้แพ็คเกจเพื่อควบคุมแหล่งที่มา http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages


3

โพสต์นี้ล้าสมัยมาก คำตอบยังคงเป็นไม่ใช่ แต่วิธีแก้ปัญหาเปลี่ยนไปแล้ว ตั้งแต่ NuGet 2.7+ คุณสามารถเปิดใช้งานการคืนค่าแพ็คเกจอัตโนมัติโดยไม่รวมไฟล์ NuGet.exe ในแหล่งที่มาของคุณ (นี่เป็นสิ่งที่ไม่พึงปรารถนาที่จะพูดอย่างน้อยที่สุด) และหากคุณใช้ DVCS ที่ทันสมัยใด ๆ คุณสามารถละเว้นโฟลเดอร์แพ็คเกจได้ หากคุณต้องการการปรับแต่งพิเศษใด ๆ คุณสามารถสร้างไฟล์ nuget.config ในรูทโซลูชัน

http://docs.nuget.org/docs/reference/package-restore

นอกจากนี้ด้วยรูปแบบ csproj ใหม่คุณสามารถหลีกเลี่ยงไฟล์ nuget.config พิเศษได้เช่นกันเนื่องจากรวมอยู่ในตอนนี้ โปรดดูโพสต์นี้ซึ่งอธิบายได้ดีกว่า:

ควรเพิ่มโฟลเดอร์. net ในการควบคุมเวอร์ชันหรือไม่

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