การตั้งค่าโฟลเดอร์แพ็กเกจ nuget ทั่วไปสำหรับโซลูชันทั้งหมดเมื่อบางโปรเจ็กต์ถูกรวมในหลายโซลูชัน

137

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

ฉันได้เห็นว่ามีวิธีที่จะชี้ให้เห็นสถานที่แพคเกจที่พบบ่อย (บางทีที่ระดับรากโครงการที่เราจะใช้การควบคุมแหล่ง TFS) ด้วยการเปิดตัว 2.1 ของ NuGet ดูบันทึกประจำรุ่น ฉันใช้ NuGet v2.7

แต่ฉันพยายามเพิ่มไฟล์ nuget.config โดยไม่เห็นผลของสิ่งนี้ แพคเกจยังคงเก็บไว้ในโฟลเดอร์โซลูชัน มีอะไรที่ฉันพลาดไปไหม? ดูเหมือนว่าจะมีโครงสร้างที่แตกต่างกันของโหนด xml เพื่อเพิ่มลงในไฟล์ nuget.config ขึ้นอยู่กับผู้ที่ตอบคำถามนั้น: Schwarzie แนะนำในเธรด Stackoverflow อื่น :

<settings>
  <repositoryPath>..\..\[relative or absolute path]</repositoryPath>
</settings>

บันทึกประจำรุ่นสำหรับ NuGet 2.1 (ดูลิงค์ด้านบน) แนะนำรูปแบบนี้: 

<configuration>
  <config>
    <add key="repositoryPath" value="..\..\[relative or absolute path]" />
  </config>
</configuration>

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

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

nuget  nuget-package  solution 
— Mats Isaksson
แหล่งที่มา
3
ฉันสงสัยว่าคำตอบสั้น ๆ สำหรับคำถามของคุณ (ซ่อนอยู่ในคำตอบของ Vermis ด้านล่าง) คือคุณพลาด$หน้าทางสัมพัทธ์ นอกจากนี้คำตอบสำหรับคำถามของคุณเกี่ยวกับไฟล์ NuGet.Config อยู่ที่นี่ด้วย อันดับแรกจะดูใน. nuget จากนั้นในไดเรกทอรีหลักทั้งหมดจากนั้นไปที่ไฟล์ 'global' ใน AppData ของคุณ: จากนั้นให้นำไปใช้ในลำดับ REVERSE (ไม่ว่ามันจะหมายถึงอะไร)
— Benjol
ดูเหมือนว่าจะเป็นเรื่องยาก มีเครื่องมือที่เรียกว่า Paket ซึ่งสามารถแก้ไขปัญหานี้ได้: fsprojects.github.io/Paket
— Tuomas Hietanen
แสดงความคิดเห็นช้า เพียงแค่ต้องการเพิ่มว่า Visual Studio จำเป็นต้องเริ่มต้นใหม่ถ้าคุณเรียกใช้เมื่อคุณเริ่มการเปลี่ยนแปลงนี้เนื่องจากไฟล์ nuget.config ดูเหมือนจะอ่านในระหว่างการเริ่มต้น VS นอกจากนี้ฉันไม่มีปัญหาหากไม่มี $ เพียงแค่ไม่เริ่มต้นด้วยแบ็กสแลช
— MBWise

คำตอบ:

147

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

  • codebase
    • โครงการ A
    • โครงการ B
    • โครงการ C
    • โซลูชั่น
      • โซลูชันที่ 1
      • โซลูชันที่ 2
      • โซลูชันที่ 3
      • แพ็คเกจ (นี่เป็นแพคเกจทั่วไปที่แชร์โดยโซลูชันทั้งหมด)

คำตอบที่อัปเดตแล้วของ NuGet 3.5.0.1484 ด้วย Visual Studio 2015 อัปเดต 3

กระบวนการนี้ง่ายขึ้นเล็กน้อยเมื่อเทียบกับตอนแรกที่ฉันจัดการกับมันและคิดว่าถึงเวลาที่จะต้องอัปเดตแล้ว โดยทั่วไปกระบวนการจะเหมือนกันเพียงไม่กี่ก้าวเท่านั้น ผลลัพธ์เป็นกระบวนการที่แก้หรือให้สิ่งต่อไปนี้:

  • ทุกสิ่งที่จำเป็นต้องได้รับการมุ่งมั่นในการควบคุมซอร์สโค้ดสามารถมองเห็นและติดตามได้ในโซลูชัน
  • การติดตั้งแพ็คเกจใหม่หรืออัพเดทแพ็คเกจโดยใช้ Package Manager ใน Visual Studio จะใช้เส้นทางที่เก็บข้อมูลที่ถูกต้อง
  • หลังจากการกำหนดค่าเริ่มต้นไม่มีการแฮ็คไฟล์. csproj
  • ไม่มีการดัดแปลงเวิร์คสเตชั่นสำหรับนักพัฒนา (รหัสพร้อมสร้างเมื่อเช็คเอาต์)

มีข้อเสียที่เป็นไปได้บางประการที่ต้องระวัง (ฉันยังไม่พบ YMMV) ดูคำตอบและความคิดเห็นของ Benolด้านล่าง

เพิ่ม NuGet.Config

คุณจะต้องการสร้างไฟล์ NuGet.Config ในรูทของโฟลเดอร์ \ Solutions \ ตรวจสอบให้แน่ใจว่านี่เป็นไฟล์ที่เข้ารหัส UTF-8 ที่คุณสร้างหากคุณไม่แน่ใจว่าจะทำเช่นไรให้ใช้ไฟล์ -> สร้าง -> เมนูของ Visual Studio จากนั้นเลือกเทมเพลตไฟล์ XML เพิ่มไปที่ NuGet กำหนดค่าต่อไปนี้:

<?xml version="1.0" encoding="utf-8"?>
<configuration>  
  <config>
    <add key="repositoryPath" value="$\..\Packages" />
  </config>
</configuration>

สำหรับการตั้งค่า repositoryPath คุณสามารถระบุพา ธ สัมบูรณ์หรือพา ธ สัมพัทธ์ (แนะนำ) โดยใช้ $ token $ token นั้นขึ้นอยู่กับที่ตั้งของ NuGet.Config (จริง ๆ แล้ว $ token นั้นสัมพันธ์กับหนึ่งระดับต่ำกว่าตำแหน่งของ NuGet.Config) ดังนั้นถ้าฉันมี \ Solutions \ NuGet.Config และฉันต้องการ \ Solutions \ แพ็คเกจฉันจะต้องระบุ $ \ .. \ แพคเกจเป็นค่า

ถัดไปคุณจะต้องเพิ่มโฟลเดอร์โซลูชันให้กับโซลูชันที่เรียกว่า "NuGet" (คลิกขวาที่โซลูชันของคุณเพิ่ม -> โฟลเดอร์โซลูชันใหม่) โซลูชันโฟลเดอร์เป็นโฟลเดอร์เสมือนที่มีอยู่ในโซลูชัน Visual Studio เท่านั้นและจะไม่สร้างโฟลเดอร์จริงบนไดรฟ์ (และคุณสามารถอ้างอิงไฟล์ได้จากทุกที่) คลิกขวาที่โฟลเดอร์โซลูชัน "NuGet" แล้วเพิ่ม -> รายการที่มีอยู่แล้วเลือก \ Solutions \ NuGet.Config

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

โดยการวางไฟล์ NuGet.Config ใน \ Solutions \ ด้านบนไฟล์. sln ใด ๆ เรากำลังใช้ประโยชน์จากข้อเท็จจริงที่ว่า NuGet จะนำทางโครงสร้างโฟลเดอร์ซ้ำ ๆ จาก "ไดเรกทอรีทำงานปัจจุบัน" เพื่อค้นหาไฟล์ NuGet.Config เพื่อใช้งาน "ไดเรกทอรีการทำงานปัจจุบัน" หมายถึงสิ่งต่าง ๆ ที่นี่หนึ่งคือเส้นทางการดำเนินการของ NuGet.exe และอื่น ๆ เป็นที่ตั้งของไฟล์. sln

สลับไปยังโฟลเดอร์แพ็คเกจของคุณ

อันดับแรกฉันขอแนะนำให้คุณดำเนินการตามแต่ละโฟลเดอร์โซลูชันและลบ \ Packages \ โฟลเดอร์ที่มีอยู่ (คุณจะต้องปิด Visual Studio ก่อน) สิ่งนี้ทำให้ง่ายต่อการดูว่า NuGet วางโฟลเดอร์ \ Packages \ ที่เพิ่งกำหนดค่าไว้ของคุณอย่างไรและทำให้แน่ใจว่าลิงก์ใด ๆ ไปยังโฟลเดอร์ \ Packages \ ผิดจะล้มเหลวและสามารถแก้ไขได้

เปิดโซลูชันของคุณใน Visual Studio และเริ่มสร้างใหม่ทั้งหมด ไม่ต้องสนใจข้อผิดพลาดของบิลด์ทั้งหมดที่คุณจะได้รับซึ่งเป็นสิ่งที่คาดว่าจะเกิด สิ่งนี้ควรเริ่มจากคุณลักษณะการกู้คืนแพ็คเกจของ NuGet เมื่อเริ่มกระบวนการสร้างอย่างไรก็ตาม ตรวจสอบว่าโฟลเดอร์ \ Solutions \ Packages \ ของคุณถูกสร้างขึ้นในจุดที่คุณต้องการ หากยังไม่ได้ตรวจสอบการกำหนดค่าของคุณ

ตอนนี้สำหรับแต่ละโครงการในโซลูชันของคุณคุณจะต้อง:

  1. คลิกขวาที่โครงการและเลือกยกเลิกการโหลดโครงการ
  2. คลิกขวาที่โครงการและเลือกแก้ไข your-xxx.csproj
  3. ค้นหาการอ้างอิงถึง \ packages \ และอัปเดตไปยังตำแหน่งใหม่
    • ส่วนใหญ่จะเป็น <HintPath> ข้อมูลอ้างอิง แต่ไม่ใช่ทั้งหมด ตัวอย่างเช่น WebGrease และ Microsoft.Bcl.Build จะมีการตั้งค่าเส้นทางแยกต่างหากที่จะต้องมีการปรับปรุง
  4. บันทึก. csproj จากนั้นคลิกขวาที่โครงการและเลือกโหลดโครงการอีกครั้ง

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

ในฐานะของ NuGet 2.7.1 (2.7.40906.75) พร้อม VStudio 2012

สิ่งแรกที่ควรคำนึงถึงคือ nuget.config ไม่ได้ควบคุมการตั้งค่าพา ธ ทั้งหมดในระบบแพ็คเกจ nuget นี่เป็นความสับสนโดยเฉพาะอย่างยิ่งที่จะคิดออก โดยเฉพาะอย่างยิ่งปัญหาคือ msbuild และ Visual Studio (การเรียกใช้ msbuild) ไม่ใช้พา ธ ใน nuget.config แต่จะแทนที่มันในไฟล์ nuget.targets

การเตรียมสิ่งแวดล้อม

ก่อนอื่นฉันจะเข้าไปยังโฟลเดอร์โซลูชันของคุณแล้วลบ \ packages \ folder ทั้งหมดที่มีอยู่ออก วิธีนี้จะช่วยให้มั่นใจได้ว่าแพ็คเกจทั้งหมดติดตั้งอย่างชัดเจนในโฟลเดอร์ที่ถูกต้องและเพื่อช่วยค้นหาการอ้างอิงเส้นทางที่ไม่ดีตลอดโซลูชัน ถัดไปฉันจะตรวจสอบให้แน่ใจว่าคุณได้ติดตั้งส่วนขยาย Visual Studio ล่าสุด nuget ฉันจะตรวจสอบให้แน่ใจว่าคุณได้ติดตั้ง nuget.exe ล่าสุดในแต่ละโซลูชัน เปิดพร้อมท์คำสั่งและไปที่แต่ละโฟลเดอร์ $ (SolutionDir) \ .nuget \ และดำเนินการคำสั่งต่อไปนี้:

nuget update -self

การตั้งค่าเส้นทางโฟลเดอร์แพคเกจทั่วไปสำหรับ NuGet

เปิดแต่ละ $ (SolutionDir) \ .nuget \ NuGet.Config และเพิ่มสิ่งต่อไปนี้ภายในส่วน <configuration>:

<config>
    <add key="repositorypath" value="$\..\..\..\Packages" />
</config>

หมายเหตุ:คุณสามารถใช้พา ธ สัมบูรณ์หรือพา ธ สัมพัทธ์ โปรดทราบว่าหากคุณใช้เส้นทางสัมพัทธ์กับ $ ว่ามันสัมพันธ์กับหนึ่งระดับต่ำกว่าที่ตั้งของ NuGet.Config (เชื่อว่านี่เป็นข้อผิดพลาด)

การตั้งค่าเส้นทางโฟลเดอร์แพคเกจทั่วไปสำหรับ MSBuild และ Visual Studio

เปิดแต่ละ $ (SolutionDir) \ .nuget \ NuGet.targets และแก้ไขหัวข้อต่อไปนี้ (โปรดทราบว่าสำหรับผู้ที่ไม่ใช่ Windows จะมีส่วนอื่นอยู่ด้านล่าง):

<PropertyGroup Condition=" '$(OS)' == 'Windows_NT'">
    <!-- Windows specific commands -->
    <NuGetToolsPath>$([System.IO.Path]::Combine($(SolutionDir), ".nuget"))</NuGetToolsPath>
    <PackagesConfig>$([System.IO.Path]::Combine($(ProjectDir), "packages.config"))</PackagesConfig>
    <PackagesDir>$([System.IO.Path]::Combine($(SolutionDir), "packages"))</PackagesDir>
</PropertyGroup>

อัพเดทแพ็คเกจ

<PackagesDir>$([System.IO.Path]::GetFullPath("$(SolutionDir)\..\Packages"))</PackagesDir>

หมายเหตุ: GetFullPath จะแก้ไขเส้นทางสัมพัทธ์ของเราให้เป็นเส้นทางสัมบูรณ์

การกู้คืนแพ็คเกจ nuget ทั้งหมดลงในโฟลเดอร์ทั่วไป

เปิดพรอมต์คำสั่งและข้ามไปแต่ละ $ (SolutionDir) \ .nuget และดำเนินการคำสั่งต่อไปนี้:

nuget restore ..\YourSolution.sln

ณ จุดนี้คุณควรมีโฟลเดอร์ \ packages \ เดียวในตำแหน่งทั่วไปของคุณและไม่มีในโฟลเดอร์โซลูชันใด ๆ ของคุณ ถ้าไม่เช่นนั้นยืนยันเส้นทางของคุณ

แก้ไขการอ้างอิงโครงการ

เปิดไฟล์. csproj ทุกไฟล์ในเท็กซ์เอดิเตอร์และค้นหาการอ้างอิงใด ๆ กับ \ packages และอัพเดตไปยังพา ธ ที่ถูกต้อง ส่วนใหญ่จะเป็น <HintPath> ข้อมูลอ้างอิง แต่ไม่ใช่ทั้งหมด ตัวอย่างเช่น WebGrease และ Microsoft.Bcl.Build จะมีการตั้งค่าเส้นทางแยกต่างหากที่จะต้องมีการปรับปรุง

สร้างโซลูชันของคุณ

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

มีข้อผิดพลาดในการสร้างเกี่ยวกับแพ็คเกจที่หายไปหรือไม่

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

nuget restore ..\YourSolution.sln
— Vermis
แหล่งที่มา
ขอบคุณสำหรับคำตอบที่ยาวเกินไปสำหรับปัญหาความยาวของฉัน ฉันจะลองวิธีนี้และกลับไปหาคุณ
— Mats Isaksson
มันจะทำงานเพื่อให้ทั้ง. sln ในไดเรกทอรีเดียวกันได้หรือไม่ พวกเขาจะลงเอยด้วยการแชร์ไดเรกทอรีแพ็คเกจเดียวกันหรือไม่
— tofutim
7
ฉันคิดว่าคำตอบนี้แสดงให้เห็นถึงวิธีการที่เข้มงวด nuget การสร้างโครงสร้างที่ซับซ้อนและซับซ้อนเพื่อให้แนวคิดง่าย ๆ เช่น: - "การแบ่งปันแอสเซมบลีเดียวกันระหว่างโซลูชัน" เป็นการบ่งบอกถึงการออกแบบที่ไม่ดีของสิ่งต่าง ๆ ทั้งหมด
— มิก
1
ยังทำงานอะไรได้บ้างในการแก้ไข HintPaths - หลังจากที่คุณอัพเดต NuGet.config ตามที่คุณต้องการในคอนโซล Package-Manager ให้รัน "Update-Package -reinstall" การดำเนินการนี้จะติดตั้งแพคเกจทั้งหมดใหม่แก้ไขคำแนะนำด้วย หลังจากนี้ - คุณอาจมีของที่ระลึกเหลืออยู่ (ฉันมีในโครงการ Silverlight - การนำเข้า "เก่า" ของเป้าหมาย / งานสร้างยังอยู่ที่นั่น)
— johannes.colmsee
1
@Vermis หากฉันตั้งค่าโฟลเดอร์แพ็คเกจทั่วไปสำหรับโซลูชันทั้งหมดของฉัน ผลกระทบของสิ่งนั้นจะเกิดขึ้นกับ Azure Devops ของฉันอย่างไร
— Pankaj Devrani
39

แทนที่จะตั้งค่าตำแหน่งแพคเกจทั่วไปสำหรับทุกโครงการคุณสามารถเปลี่ยน HintPath ในโครงการดังต่อไปนี้:

<HintPath>$(SolutionDir)\packages\EntityFramework.6.1.0\lib\net40\EntityFramework.dll</HintPath>

ในกรณีส่วนใหญ่ที่มีในโครงการที่ใช้ร่วมกันจะมีเพียงไม่กี่แพคเกจดังนั้นคุณสามารถเปลี่ยนได้อย่างง่ายดาย

ฉันคิดว่ามันเป็นทางออกที่ดีกว่าเมื่อคุณแยกรหัสเมื่อตั้ง repo ทั่วไปคุณต้องเปลี่ยนเส้นทางสัมพัทธ์ในโซลูชันนี้คุณไม่จำเป็นต้องทำ

— Adam Wyżgoł
แหล่งที่มา
2
อดัมถูกต้อง นี่เป็นวิธีที่ง่ายที่สุดในการแก้ปัญหาที่โง่เขลาอย่างไม่น่าเชื่อ
— lapsus
1
มันเป็นทางออกที่ยอดเยี่ยม ง่ายและชัดเจนที่ไม่ต้องการการสร้างโครงสร้างของรหัสใด ๆ
— RredCat
2
AFAIK $ (SolutionDir) จะถูกตั้งค่าเมื่อสร้างเสร็จผ่าน VS ดังนั้นจึงไม่มีสิ่งปลูกสร้างโดยตรงผ่าน msbuild.exe เว้นแต่คุณจะตั้งค่า / p: SolutionDir = path
— Lars Nielsen
สามารถตั้งค่านี้ได้โดยอัตโนมัติที่นี่% APPDATA% \ โรมมิ่ง \ NuGet \ NuGet.Config
— Korayem
15
วิธีนี้ใช้งานได้ดีจนกระทั่งคุณอัปเดตแพ็คเกจและเขียนทับ HintPath ด้วยเส้นทางสัมพัทธ์ใหม่ กลายเป็นเรื่องน่าเบื่อในโซลูชันขนาดใหญ่ที่มีแพ็คเกจจำนวนมาก พระเจ้าห้ามคุณต้องเรียกใช้แพคเกจการอัพเดท - ติดตั้งใหม่ ...
— gravidThoughts
22

ประสบการณ์ของฉันลองทำสิ่งนี้ด้วย NuGet (2.7) และ VS2012 เวอร์ชันล่าสุด:

  • ลบโฟลเดอร์. nuget (บนดิสก์และในโซลูชัน)
  • วางไฟล์ NuGet.Config ในโฟลเดอร์พาเรนต์ทั่วไปของโซลูชันทั้งหมด
  • ลบโฟลเดอร์แพ็คเกจที่มีอยู่
  • ผ่านไฟล์ csproj ทั้งหมดและเปลี่ยน HintPaths เพื่อชี้ไปยังตำแหน่งใหม่
  • กำไร

ในกรณีของฉันฉันต้องการใส่แพ็คเกจทั้งหมด.packagesดังนั้น NuGet.Config ของฉันจึงมีลักษณะดังนี้

 <?xml version="1.0" encoding="utf-8"?>
 <configuration>
   <config>
     <add key="repositorypath" value=".packages" />
   </config>
 </configuration>

โปรดทราบว่ามีบางสิ่งที่ 'แปลก' ที่สามารถเกิดขึ้นได้ แต่ฉันคิดว่าพวกมันสามารถรับได้

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

ข้อจำกัดความรับผิดชอบ : ฉันเพิ่งลองทำวันนี้ฉันไม่มีประสบการณ์ระยะยาวในการสำรองข้อมูล!

— Benjol
แหล่งที่มา
4
นี่คือวิธีที่แนะนำที่จะทำมัน วิธีการรวม msbuild แบบเก่าเพื่อทำการคืนค่า nuget ในคำตอบที่ยอมรับได้คือ pita และฉันสามารถยืนยันได้ว่าใส่ NuGet.config ไว้ข้างๆ sln ที่ทำงานกับเราด้วย Automatic Package Restore วางไว้ในไดเรกทอรีหลักทั่วไปฉันไม่สามารถยืนยันได้
— 9swampy
1
วิธีวาง NuGet.Config ในโฟลเดอร์พาเรนต์ทั่วไปสำหรับโซลูชันทั้งหมด (ใน TFS) เพื่อให้สามารถอ้างอิงได้ วิธีเดียวที่ฉันรู้ก็คือโฟลเดอร์. nuget ภายใต้โซลูชันทุกตัวที่มีไฟล์ nuget.config และถ้า "repositorypath = .packages" มันจะสร้างโฟลเดอร์ย่อยภายใต้ .uget like: C: \ TFS \ Comp \ Ent \ SolABC \ .nuget \ .packages - สิ่งนี้ไม่สามารถแก้ปัญหาโครงการ / โซลูชันที่ซ้อนกันได้ ที่ควรทำงานกับการสร้าง TFS อัตโนมัติ คำตอบที่ได้รับการยอมรับต้องใช้งานที่เขียนด้วยมือรวมทั้ง "repositorypath value = $ \ .. \ .. \ .. \ แพคเกจสิ่งนี้จะไม่ทำงานหากมีโครงการที่ซ้อนกันที่มีเส้นทางสัมพัทธ์ต่างกัน
— hB0
2
ทำงานร่วมกับ Visual Studio 2015 และ Nuget 3.4.3
— HüseyinYağlı
ไม่เพียง แต่จะลบแพ็กเกจรุ่นเก่าทันที แต่จะเขียนทับและทำลาย HintPath ที่คุณได้เข้ารหัสลงในไฟล์ csproj @ hB0 ถูกต้อง ใช้งานได้กับโซลูชันที่ค่อนข้างง่ายเท่านั้น เมื่อคุณเข้าสู่โครงสร้างเวิร์กสเปซ TFS ที่ซับซ้อนด้วยสาขาโครงการที่ใช้ร่วมกัน ฯลฯ มันไม่สามารถปรับขนาดได้อย่างมีประสิทธิภาพ
— gravidThoughts
20

ฉันมี NuGet รุ่น 2.8.50926 กับ VS 2013 คุณไม่จำเป็นต้องใช้ไฟล์ nuget.config หลายไฟล์หรือใช้โครงสร้างไดเรกทอรีที่ซับซ้อน เพียงแก้ไขไฟล์เริ่มต้นที่อยู่ที่นี่:

%APPDATA%\Roaming\NuGet\NuGet.Config

นี่คือเนื้อหาของไฟล์ของฉัน:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
    <add key="repositoryPath" value="C:\Projects\nugetpackages" />
  </config>
  <activePackageSource>
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
  </activePackageSource>
</configuration>

ดังนั้นแพ็คเกจทั้งหมดไปที่โฟลเดอร์ "C: \ Projects \ nugetpackages" ไม่ว่าโซลูชันจะอยู่ที่ใด

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

— Matthieu
แหล่งที่มา
นี่คือทางออกที่ง่ายที่สุดของทั้งหมดและสมควรได้รับความรักมากขึ้น!
— Korayem
2
นี่คือวันนี้ทางออกที่ง่ายที่สุดแน่นอน แต่สิ่งหนึ่งที่ขาดหายไปในคำตอบของคุณ คุณยังต้องจัดการกับ HintPath ในไฟล์ csproj ของแต่ละโครงการ พวกเขาจะไม่ถูกกำหนดเป้าหมายโดยอัตโนมัติไปยังเส้นทางใหม่ ฉันถูกไหม?
— batmaci
อันที่จริงในโครงการเก่าของฉันบางครั้งมีการอ้างอิงไปยังโฟลเดอร์แพ็คเกจ "เก่า" อย่างไรก็ตามสำหรับฉันทุกอย่างทำงานได้อย่างถูกต้องดังนั้นฉันเดาว่าการตั้งค่าทั่วโลกจะมีความสำคัญกว่า
— Matthieu
สำหรับ OSX ดูdocs.microsoft.com/en-us/nuget/consume-packages/... ฉันชอบแนวคิด mklink ด้านล่างด้วย
— sgtz
3

จาก Visual Studio 2013 Update 4 และเวอร์ชัน Nugget Package Manager> 2.8.5 ...

สร้างไฟล์ nuget.config ในรูทของที่เก็บ

เนื้อหาไฟล์:

<configuration>
  <config>
    <add key="repositoryPath" value="packages" />
  </config>
  <packageSources>
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
  </packageSources>
</configuration>

ซึ่งจะทำให้แพ็คเกจทั้งหมดไปที่โฟลเดอร์ packages ในระดับของไฟล์ nuget.config ของคุณ

ตอนนี้คุณสามารถไปสำหรับคอนโซล. nuget แต่ละอันด้วยคำสั่ง 'update-package -reinstall'

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

 <add key="repositoryPath" value="..\packages" />

แต่ด้วยวิธีนี้คุณทำให้การอ้างอิงแพคเกจ nuget csproj ชี้ไปที่โฟลเดอร์หนึ่งนอกคุณที่เก็บพา ธ

— Janusz Nowak
แหล่งที่มา
3

ฉันได้เตรียมแพ็คเกจ NuGet ที่แปลงการอ้างอิง NuGet ทั้งหมดในโครงการเป็นรูปแบบสัมพัทธ์ $ (SolutionDir) มันใช้การแปลง XSLT แบบ build-time ดังนั้นคุณไม่จำเป็นต้องแฮ็คไฟล์โครงการด้วยมือ คุณสามารถอัพเดทแพ็คเกจได้อย่างอิสระมันจะไม่ทำลายอะไรเลย

https://www.nuget.org/packages/NugetRelativeRefs

หรือคุณถ้าคุณใช้ Visual Studio 2015 อัปเดต 3 คุณสามารถโยกย้ายการอ้างอิงแพ็คเกจของคุณไปยังproject.jsonแบบฟอร์มตามที่อธิบายไว้ที่นี่: https://oren.codes/2016/02/08/project-json-all-the-things

— Oleg Tarasov
แหล่งที่มา
แต่น่าเสียดายที่ดูเหมือนว่าไมโครซอฟท์จะย้ายออกไปจาก project.json นอกจากนี้ฉันชอบแพ็คเกจนักเก็ตของคุณ บางเวลาที่ผ่านมาฉันใช้NuGetReferenceHintPathRewriteซึ่งทำสิ่งเดียวกัน แต่แตกต่างกันมาก
— Andrey Borisko
2

อัปเดตประสบการณ์ของฉันด้วย nuget 2.8.3 มันค่อนข้างง่าย ทั้งหมดเปิดใช้งานการกู้คืนแพ็กเกจจากโซลูชันคลิกขวา แก้ไข NuGet.Configและเพิ่มบรรทัดเหล่านี้:

  <config>
    <add key="repositorypath" value="..\Core\Packages" />
  </config>

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

นี่เป็นขั้นตอนตามขั้นตอนเพื่อเปิดใช้งานแพคเกจคืนค่า

http://blogs.4ward.it/enable-nuget-package-restore-in-visual-studio-and-tfs-2012-rc-to-building-windows-8-metro-apps/

— Amarnath chatterjee
แหล่งที่มา
2

เพียง hardlink / แพ็คเกจไปยังตำแหน่งที่ใช้ร่วมกันที่ต้องการ จากนั้นโครงการของคุณจะไม่ถูกทำลายสำหรับผู้ใช้รายอื่นซึ่งไม่มีที่ตั้งแพ็กเกจพิเศษ

เปิดพรอมต์คำสั่งในฐานะผู้ดูแลระบบและใช้

mklink /prefix link_path Target_file/folder_path
— user803469
แหล่งที่มา
2

สำหรับการแก้ปัญหาที่สำคัญคำตอบข้างต้นจะสั้น ค่อนข้างง่ายโครงสร้างเวิร์กสเปซ TFS ที่ซับซ้อนซึ่งมีพา ธ สัมพัทธ์ที่แตกต่างกันการแบรนช์โครงการที่ใช้ร่วมกัน ฯลฯ ทำให้ที่เก็บส่วนกลางเดียวเป็นไปไม่ได้

การใช้ ($ SolutionDir) เป็นขั้นตอนในทิศทางที่ถูกต้อง แต่การเข้ารหัสไฟล์ csproj ด้วย ($ SolutionDir) ด้วยมือจะกลายเป็นเรื่องน่าเบื่อหน่ายในฐานรหัสที่มีหลายร้อยแพ็คเกจที่อัปเดตเป็นประจำ (อัพเดททุกครั้งเกิดขึ้น HintPath จะเขียนทับด้วย เส้นทางสัมพัทธ์ใหม่) จะเกิดอะไรขึ้นถ้าคุณต้องเรียกใช้ Update-Package - ติดตั้งใหม่

มีวิธีที่ดีที่เรียกว่าเป็นNugetReferenceHintPathRewrite โดยจะทำการฉีด ($ SolutionDir) ลงใน HintPaths ก่อนที่จะสร้าง (โดยไม่ต้องเปลี่ยนไฟล์ csproj จริง) ฉันคิดว่ามันสามารถรวมเข้ากับระบบสร้างอัตโนมัติได้อย่างง่ายดาย

— gravidThoughts
แหล่งที่มา
1

สรุปย่อสำหรับผู้ที่อยู่ในVS 2013 professionalพร้อมNuGet Version: 2.8.60318.667

นี่คือวิธีที่คุณจะนำแพคเกจไปยังเส้นทางที่เกี่ยวข้องกับโฟลเดอร์. nuget:

<configuration>
  <config>
    <add key="repositoryPath" value="../Dependencies" />
  </config>
</configuration>

ตัวอย่างเช่นหากโซลูชัน (ไฟล์. sln) ของคุณอยู่ใน C: \ Projects \ MySolution เมื่อคุณเปิดใช้งานการเรียกคืนแพคเกจ NuGet โฟลเดอร์. snuget จะถูกสร้างขึ้นเช่น: C: \ Projects \ MySolution.nuget และแพ็คเกจจะถูกดาวน์โหลด ไปยังไดเรกทอรีเช่น: C: \ Projects \ MySolution \ Dependencies

หมายเหตุ:ด้วยเหตุผลบางอย่าง (ไม่ทราบ) ทุกครั้งที่ฉันอัปเดต "repositoryPath" ฉันต้องปิดและเปิดโซลูชันอีกครั้งเพื่อให้การเปลี่ยนแปลงมีผล

— Sudhanshu Mishra
แหล่งที่มา
โปรดทราบว่ามีเครื่องหมายทับบนแท็กการกำหนดค่าปิดหายไป
— หมู่ที่
— HANiS
0

สำหรับผู้ที่ใช้ paket เป็นผู้จัดการแพ็คเกจมีตัวเลือก symlink อัตโนมัติสำหรับไฟล์การอ้างอิงของคุณ:

storage: symlink

btw: paket ใช้ประโยชน์จาก nuget

การอ้างอิง: https://fsprojects.github.io/Paket/dependencies-file.html

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

— sgtz
แหล่งที่มา
0

ฉันเพิ่งใช้การเชื่อมต่อระบบไฟล์ NTFS เพื่อสร้างโฟลเดอร์แพ็คเกจทั้งหมดไปยังโฟลเดอร์เดียวที่อยู่เหนือรากที่เก็บ ใช้งานได้ดี ไม่มีปัญหากับแพคเกจแบบขนานเรียกคืนในโซลูชันที่หลากหลาย ข้อดีอย่างหนึ่งของสิ่งนี้คือคุณไม่จำเป็นต้องกำหนดค่าอะไรใหม่ในซอร์สโค้ดของคุณเช่นเส้นทางบอกใบ้สัมพัทธ์หลายร้อยไฟล์ในไฟล์. csproj ของคุณ มัน 'ใช้งานได้' โดยให้ระบบไฟล์จัดการการเปลี่ยนเส้นทางและการจำลองของโฟลเดอร์แพ็คเกจเดียว

เพียงระวังปัญหา 'git' แม้ว่า 'คอมไพล์สถานะ' ผ่านทางคำสั่งแสดงให้เห็นว่าไม่มีการเปลี่ยนแปลงบรรทัด unstaged ผมสังเกตเห็นว่า GitKraken เห็น 'แพคเกจ' แยกเป็น unstaged ไฟล์ มันยังแสดงข้อผิดพลาดเช่น 'file is a directory' เมื่อคุณคลิก GitKraken จะพยายามซ่อน 'ไฟล์' นี้หากคุณรีบูตทำลายจุดเชื่อมต่อและเรียกคืนเป็นไฟล์จริงที่มีข้อความพร้อมกับเส้นทางไฟล์ต้นฉบับ พฤติกรรมที่แปลกมาก อาจสามารถแก้ไขได้ด้วยการเพิ่มไฟล์แพ็คเกจลงใน. gitignore ของคุณ

— Triynko
แหล่งที่มา
-1

คำแนะนำเหล่านี้เป็นของ NuGet 2.1: http://docs.nuget.org/docs/release-notes/nuget-2.1

ไม่จำเป็นต้องแก้ไขไฟล์ระดับโซลูชัน

ทำงานร่วมกับ Visual Studio 2013 และสามโซลูชันที่แชร์โปรเจ็กต์

อย่าลืมอัปเดตโซลูชันระดับ NuGet (แต่ละ nuget.exe ในโฟลเดอร์. nuget)

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