जब कुछ परियोजनाओं को कई समाधानों में शामिल किया जाता है, तो सभी समाधानों के लिए एक सामान्य नगेट संकुल फ़ोल्डर की स्थापना की जाती है

137

मैं बाहरी और आंतरिक पैकेज स्रोतों से पैकेज प्राप्त करने के लिए NuGet का उपयोग कर रहा हूं, जो बहुत सुविधाजनक है। लेकिन मुझे एहसास हुआ कि पैकेज डिफ़ॉल्ट रूप से प्रति समाधान संग्रहीत होते हैं, जो बहुत ही निराशाजनक है जब NuGet संदर्भ वाली कुछ परियोजनाएं कई समाधानों में शामिल हैं। फिर संदर्भों को अन्य समाधान पैकेज फ़ोल्डर में बदल दिया जाता है जो वास्तव में किसी अन्य डेवलपर या निर्माण मशीन के लिए अनुपलब्ध हो सकता है।

मैंने देखा है कि NuGet की रिलीज़ 2.1 के साथ एक सामान्य पैकेज स्थान (शायद परियोजना रूट स्तर पर, हम TFS स्रोत नियंत्रण का उपयोग कर रहे हैं) को इंगित करने के तरीके हैं, रिलीज़ नोट देखें । मैं NuGet v2.7 का उपयोग कर रहा हूं

लेकिन मैंने इसके किसी भी प्रभाव को देखे बिना nuget.config फ़ाइलों को जोड़ने का प्रयास किया है। पैकेज अभी भी समाधान फ़ोल्डर में संग्रहीत हैं। क्या मुझे कुछ याद है? प्रतीत होता है कि nuget.config फ़ाइल में जोड़ने के लिए xml नोड की अलग-अलग संरचनाएँ हैं, जो इस प्रश्न का उत्तर दे रही है, इस पर निर्भर करती है: श्वार्ज़ी एक और स्टैकवर्मफ़्लो थ्रेड पर सुझाव देती है :

<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 
— मैट इसाकसन
स्रोत
3
मुझे संदेह है कि आपके प्रश्न का संक्षिप्त उत्तर (नीचे दिए गए वर्मिस में छिपा हुआ है) यह है कि आप $रिश्तेदार पथ के सामने से गायब थे । इसके अलावा, NuGet.Config फ़ाइलों के बारे में आपके प्रश्न का उत्तर यहाँ है । यह .nuget में पहली दिखता है, तो सभी माता पिता निर्देशिका में है, तो अपने AppData में 'वैश्विक' फ़ाइल पर: फिर उन्हें उलटे क्रम में लागू होता है (जो कुछ भी है कि इसका मतलब है)।
— बेंजोल
यह कठिन प्रतीत होता है। एक उपकरण है जिसे Paket कहा जाता है जो इस समस्या का समाधान हो सकता है: fsprojects.github.io/Paket
— Tuomas Hietanen
देर से टिप्पणी। यदि आप इस परिवर्तन को शुरू करते समय इसे चला रहे हैं तो विज़ुअल स्टूडियो को फिर से शुरू करने की आवश्यकता है, क्योंकि VS स्टार्टअप के दौरान nuget.config फ़ाइलों को पढ़ा जाना प्रतीत होता है। इसके अलावा, मुझे $ के बिना कोई समस्या नहीं थी, बस बैकस्लैश के साथ शुरू न करें।
— एमबी वाइज

जवाबों:

147

मेरे पास बाहरी और आंतरिक पैकेज स्रोतों के साथ समान स्थिति है जिसमें एक से अधिक समाधान में संदर्भित परियोजनाओं के साथ है। मुझे आज यह हमारे एक कोड बेस के साथ काम कर रहा है और ऐसा लगता है कि यह डेवलपर वर्कस्टेशन और हमारे बिल्ड सर्वर के साथ काम कर रहा है। नीचे की प्रक्रिया में इस परिदृश्य को ध्यान में रखा गया है (हालांकि यह सामान्य संकुल फ़ोल्डर के लिए अनुकूल होना मुश्किल नहीं होना चाहिए जहां)।

  • codebase
    • प्रोजेक्ट ए
    • प्रोजेक्ट बी
    • प्रोजेक्ट सी
    • समाधान
      • समाधान 1
      • समाधान २
      • समाधान 3
      • पैकेज (यह सभी समाधानों द्वारा साझा किया गया आम है)

विजुअल स्टूडियो 2015 अपडेट 3 के साथ NuGet 3.5.0.1484 के रूप में अपडेट किया गया उत्तर

यह प्रक्रिया अब थोड़ी आसान है जब मैंने मूल रूप से इससे निपटा था और सोचा था कि इसे अपडेट करने का समय आ गया है। सामान्य तौर पर, प्रक्रिया कम चरणों के साथ ही होती है। परिणाम एक प्रक्रिया है जो निम्नलिखित को हल करती है या प्रदान करती है:

  • स्रोत कोड नियंत्रण में आने वाली सभी चीजों को समाधान में दिखाई और ट्रैक किया जाता है
  • विज़ुअल स्टूडियो में पैकेज मैनेजर का उपयोग करके नए पैकेज स्थापित करना या पैकेज अपडेट करना सही रिपॉजिटरी पथ का उपयोग करेगा
  • प्रारंभिक कॉन्फ़िगरेशन के बाद, .csproj फ़ाइलों की हैकिंग नहीं
  • डेवलपर वर्कस्टेशन का कोई संशोधन (कोड चेक आउट पर तैयार नहीं है)

के बारे में पता करने के लिए कुछ संभावित डाउनसाइड हैं (मुझे अभी तक उनका अनुभव नहीं है, वाईएमएमवी)। देखिये बेनोल कानीचे जवाब और टिप्पणी।

NuGet.Config जोड़ें

आप \ समाधान \ फ़ोल्डर की जड़ में एक NuGet.Config फ़ाइल बनाना चाहते हैं। सुनिश्चित करें कि यह एक UTF-8 एन्कोडेड फ़ाइल है जिसे आप बनाते हैं, यदि आप सुनिश्चित नहीं हैं कि यह कैसे करना है, तो Visual Studio की फ़ाइल-> नई-> फ़ाइल मेनू का उपयोग करें और फिर XML फ़ाइल टेम्पलेट चुनें। निम्नलिखित में NuGet.Config में जोड़ें:

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

रिपॉजिटरीपाथ सेटिंग के लिए, आप $ टोकन का उपयोग करके एक पूर्ण पथ या रिश्तेदार पथ (अनुशंसित) निर्दिष्ट कर सकते हैं। $ टोकन उस जगह पर आधारित है जहां NuGet.Config स्थित है ($ टोकन वास्तव में NuGet.Config के स्थान के नीचे एक स्तर के सापेक्ष है)। इसलिए, अगर मेरे पास \ Solutions \ NuGet.Config है और मुझे \ Solutions \ Package चाहिए, तो मुझे मूल्य के रूप में $ \ .. \ पैकेज निर्दिष्ट करने की आवश्यकता होगी।

इसके बाद, आप एक समाधान फ़ोल्डर जोड़ना चाहेंगे जिसका नाम "नुगेट" जैसा कुछ हो। आपके समाधान पर राइट-क्लिक करें, Add-> नया समाधान फ़ोल्डर)। सॉल्यूशन फोल्डर वर्चुअल फोल्डर हैं जो केवल विजुअल स्टूडियो सॉल्यूशन में मौजूद हैं और ड्राइव पर एक वास्तविक फोल्डर नहीं बनाएंगे (और आप फाइलों को कहीं से भी रेफर कर सकते हैं)। अपने "NuGet" समाधान फ़ोल्डर पर राइट-क्लिक करें और फिर जोड़ें-> मौजूदा आइटम और \ Solutions \ NuGet.Colfig का चयन करें।

हम ऐसा कर रहे हैं इसका कारण यह है कि यह समाधान में दिखाई दे रहा है और यह सुनिश्चित करने में मदद करनी चाहिए कि यह आपके स्रोत कोड नियंत्रण के लिए ठीक से प्रतिबद्ध है। आप अपने साझाकरण परियोजनाओं में भाग लेने वाले अपने कोडबेस में प्रत्येक समाधान के लिए यह कदम उठाना चाह सकते हैं।

किसी भी .sln फ़ाइलों के ऊपर \ समाधान \ में NuGet.Config फ़ाइल रखकर, हम इस तथ्य का लाभ उठा रहे हैं कि NuGet "वर्तमान कार्यशील निर्देशिका" से फ़ोल्डर संरचना को ऊपर की ओर नेविगेट करेगा ताकि उपयोग करने के लिए NuBet.Config फ़ाइल की तलाश हो। "करंट वर्किंग डायरेक्टरी" का अर्थ है यहाँ पर कुछ अलग चीज़ें हैं, एक है NuGet.exe का निष्पादन पथ और दूसरा है .sln फ़ाइल का स्थान।

अपने पैकेज फ़ोल्डर पर स्विच करना

सबसे पहले, मैं आपको अपने प्रत्येक समाधान फ़ोल्डर के माध्यम से जाने की सलाह देता हूं और मौजूद किसी भी \ पैकेज \ फ़ोल्डर को हटा देता हूं (आपको पहले विजुअल स्टूडियो को बंद करने की आवश्यकता होगी)। इससे यह देखना आसान हो जाता है कि नुगेट आपके नए कॉन्फ़िगर किए गए \ पैकेज \ फ़ोल्डर को कहां रख रहा है और यह सुनिश्चित करता है कि गलत \ संकुल \ फ़ोल्डर के किसी भी लिंक विफल हो जाएंगे और फिर तय किए जा सकते हैं।

Visual Studio में अपना समाधान खोलें और सभी को फिर से बनाएँ। आपके द्वारा प्राप्त की गई सभी त्रुटियों को अनदेखा करें, यह इस बिंदु पर अपेक्षित है। यह हालांकि निर्माण प्रक्रिया की शुरुआत में NuGet पैकेज पुनर्स्थापना सुविधा को बंद कर देना चाहिए। सत्यापित करें कि आपका \ समाधान \ संकुल \ फ़ोल्डर उस स्थान पर बनाया गया है जिसे आप चाहते हैं। यदि यह नहीं है, तो अपने कॉन्फ़िगरेशन की समीक्षा करें।

अब, अपने समाधान में प्रत्येक परियोजना के लिए आप निम्न करना चाहेंगे:

  1. प्रोजेक्ट पर राइट-क्लिक करें और अनलोड प्रोजेक्ट चुनें
  2. प्रोजेक्ट पर राइट-क्लिक करें और Edit your-xxx.csproj चुनें
  3. किसी भी संदर्भ को '' संकुल '' खोजें और उन्हें नए स्थान पर अद्यतन करें।
    • इनमें से अधिकांश <HintPath> संदर्भ होंगे, लेकिन उनमें से सभी नहीं। उदाहरण के लिए, WebGrease और Microsoft.Bcl.Bild में अलग-अलग पथ सेटिंग्स होंगी जिन्हें अपडेट करना होगा।
  4. .Csproj को सहेजें और फिर प्रोजेक्ट पर राइट-क्लिक करें और रीलोड प्रोजेक्ट चुनें

एक बार आपकी सभी .csproj फाइलें अपडेट हो जाने के बाद, दूसरे को फिर से बनाएं और सभी को मिसिंग रेफरेंस के बारे में और अधिक गलतियां नहीं करनी चाहिए। इस बिंदु पर आप कर रहे हैं, और अब एक साझा संकुल फ़ोल्डर का उपयोग करने के लिए NuGet कॉन्फ़िगर किया गया है।

2012 के VStudio के साथ NuGet 2.7.1 (2.7.40906.75) के रूप में

सबसे पहले ध्यान रखने वाली बात यह है कि nuget.config नगेट पैकेज सिस्टम में सभी पथ सेटिंग्स को नियंत्रित नहीं करता है। यह विशेष रूप से यह पता लगाने के लिए भ्रामक था। विशेष रूप से, समस्या यह है कि msbuild और Visual Studio (msbuild को कॉल करते हुए) nuget.config में पथ का उपयोग नहीं करते हैं, बल्कि इसे nuget.targets फ़ाइल में ओवरराइड कर रहे हैं।

पर्यावरण की तैयारी

सबसे पहले, मैं आपके समाधान के फ़ोल्डर के माध्यम से जाऊँगा और मौजूद सभी \ संकुल \ फ़ोल्डरों को निकालूँगा। यह सुनिश्चित करने में मदद करेगा कि सभी पैकेज दृष्टिगत रूप से सही फ़ोल्डर में स्थापित हो रहे हैं और आपके पूरे समाधान में किसी भी खराब पथ संदर्भ को खोजने में मदद करते हैं। इसके बाद, मैं सुनिश्चित करूंगा कि आपके पास नवीनतम नगेट विजुअल स्टूडियो एक्सटेंशन स्थापित हो। मैं यह भी सुनिश्चित करूंगा कि आपके पास प्रत्येक समाधान में नवीनतम nuget.exe स्थापित है। एक कमांड प्रॉम्प्ट खोलें और प्रत्येक $ (SolutionDir) \ .nuget \ फ़ोल्डर में जाएं और निम्नलिखित कमांड निष्पादित करें:

nuget update -self

NuGet के लिए सामान्य पैकेज फ़ोल्डर पथ सेट करना

प्रत्येक $ (SolutionDir) \ .nuget \ NuGet.Config को खोलें और <b> के अंदर निम्नलिखित जोड़ें:

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

नोट: आप एक निरपेक्ष पथ या एक सापेक्ष पथ का उपयोग कर सकते हैं। ध्यान रखें, यदि आप $ के साथ एक सापेक्ष पथ का उपयोग कर रहे हैं कि यहNuGet.Config के स्थान के नीचे एक स्तर के सापेक्ष है (विश्वास करें कि यह एक बग है)।

MSBuild और Visual Studio के लिए सामान्य पैकेज फ़ोल्डर पथ सेट करना

प्रत्येक $ (SolutionDir) \ .nuget \ NuGet.targets खोलें और निम्न अनुभाग को संशोधित करें (ध्यान दें कि गैर-विंडोज के लिए इसके नीचे एक और खंड है):

<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>

PackageDir को अद्यतन करें

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

नोट: GetFullPath हमारे सापेक्ष पथ को एक पूर्ण पथ में हल करेगा।

सामान्य फ़ोल्डर में सभी नगेट संकुल को पुनर्स्थापित करना

एक कमांड प्रॉम्प्ट खोलें और प्रत्येक $ गोटो (सॉल्यूडिर) \ .नेट करें और निम्नलिखित कमांड निष्पादित करें:

nuget restore ..\YourSolution.sln

इस बिंदु पर, आपके पास अपने सामान्य स्थान पर एक एकल \ संकुल \ फ़ोल्डर होना चाहिए और आपके किसी भी समाधान फ़ोल्डर के भीतर नहीं होना चाहिए। यदि नहीं, तो अपने रास्तों का सत्यापन करें।

परियोजना संदर्भों को ठीक करना

टेक्स्ट एडिटर में प्रत्येक .csproj फ़ाइल खोलें और किसी भी संदर्भ को \ पैकेज में खोजें और उन्हें सही पथ पर अपडेट करें। इनमें से अधिकांश <HintPath> संदर्भ होंगे, लेकिन उनमें से सभी नहीं। उदाहरण के लिए, WebGrease और Microsoft.Bcl.Build में अलग-अलग पथ सेटिंग होंगी जिन्हें अपडेट करने की आवश्यकता होगी।

अपना समाधान बनाएँ

विजुअल स्टूडियो में अपना समाधान खोलें और एक बिल्ड को किक करें। यदि यह लापता पैकेजों के बारे में शिकायत करता है, जिन्हें बहाल करने की आवश्यकता है, तो यह न मानें कि पैकेज गायब है और इसे पुनर्स्थापित करने की आवश्यकता है (त्रुटि भ्रामक हो सकती है)। यह आपकी .csproj फ़ाइलों में से एक खराब पथ हो सकता है। पैकेज को पुनर्स्थापित करने से पहले पहले जांचें।

लापता पैकेज के बारे में एक बिल्ड त्रुटि है?

यदि आपने पहले ही सत्यापित कर लिया है कि आपकी .csproj फ़ाइलों में पथ सही हैं, तो आपके पास प्रयास करने के लिए दो विकल्प हैं। यदि यह स्रोत कोड नियंत्रण से अपने कोड को अपडेट करने का परिणाम है तो आप एक स्वच्छ कॉपी की जाँच करने और फिर उस निर्माण का प्रयास कर सकते हैं। यह हमारे डेवलपर्स में से एक के लिए काम करता है और मुझे लगता है कि .suo फ़ाइल या कुछ इसी तरह की एक कलाकृति थी। अन्य विकल्प मैन्युअल रूप से प्रश्न में समाधान के .nuget फ़ोल्डर में कमांड लाइन का उपयोग करके एक पैकेज को पुनर्स्थापित करने के लिए है:

nuget restore ..\YourSolution.sln
— vermis
स्रोत
मेरी लम्बी समस्या के लम्बे उत्तर के लिए धन्यवाद। मैं इस समाधान की कोशिश करूंगा और आपके पास वापस आऊंगा।
— मेट्स इस्कसन
क्या यह एक ही निर्देशिका में दोनों .sln के लिए काम करेगा? क्या वे समान पैकेज निर्देशिका साझा करना समाप्त करेंगे?
— टॉफूटिम
7
मुझे लगता है कि यह जवाब दर्शाता है कि कठोर नगेट कैसा है। इस तरह की एक सरल अवधारणा को सक्षम करने के लिए इस तरह के एक जटिल, कठोर संरचना का निर्माण करना: - "समाधानों के बीच एक ही असेंबलियों को साझा करना" पूरी बात के खराब डिजाइन का संकेत है।
— मिक
1
HintPaths को ठीक करने के लिए भी क्या काम करता है - आपके द्वारा अपनी पसंद के हिसाब से NuGet.config को अपडेट करने के बाद, पैकेज-मैनेजर कंसोल में "अपडेट-पैकेज -reinstall" चलाएं। यह उनके hintpaths को ठीक करते हुए सभी पैकेजों को फिर से स्थापित करेगा। इसके बाद - आपके पास कुछ अवशेष रह सकते हैं (मुझे कुछ चांदी के प्रोजेक्ट में - लक्ष्य / बिल्ड का "पुराना" आयात अभी भी था)
— johannes.colmsee
1
@Vermis यदि मैं अपने सभी समाधानों के लिए सामान्य नगेट संकुल फ़ोल्डर सेटअप करता हूँ। मेरे Azure Devops के निर्माण पर इसका क्या प्रभाव पड़ेगा?
— पंकज देवरानी
39

सभी परियोजनाओं के लिए आम पैकेज स्थान निर्धारित करने के बजाय, प्रोजेक्ट को निम्नलिखित के रूप में HintPath में बदलना संभव है:

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

साझा परियोजना में ज्यादातर मामलों में केवल कुछ पैकेज होंगे, ताकि आप इसे आसानी से बदल सकें।

मुझे लगता है कि यह बेहतर उपाय है, जब आप कोड को ब्रांच करते हैं, जब सामान्य रेपो सेट करते हैं, तो आपको सापेक्ष पथ बदलना होगा, इस समाधान में आपको ऐसा करने की आवश्यकता नहीं है।

— एडम व्यागोएल
स्रोत
2
आदम सही है। यह एक अविश्वसनीय बेवकूफ समस्या का सबसे सरल समाधान है।
— लैपस
1
यह शानदार समाधान है। सरल और स्पष्ट है कि किसी भी कोड संरचना के पुनर्निर्माण की आवश्यकता नहीं है।
— र्रेडकट
2
AFAIK $ (SolutionDir) केवल तब सेट होता है जब बिल्ड VS के माध्यम से किया जाता है। तो कोई निर्माण सीधे msbuild.exe के माध्यम से, जब तक कि आप सेटिंग / पी: SolutionDir = पथ नहीं करते
— लार्स नीलसन
इसे यहां स्वचालित रूप से% APPDATA% \ Roaming \ NuGet \ NuGet.Config
— Korayem
15
जब तक आप पैकेज को अपडेट नहीं करते तब तक यह बहुत अच्छा काम करता है, और एक नए रिश्तेदार पथ के साथ हिंटपाथ को ओवरराइट करें। बहुत सारे पैकेज के साथ एक बड़े समाधान में बहुत थकाऊ हो जाता है। भगवान न करें आपको एक अपडेट-पैकेज चलाना है -Reinstall ...
— 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.config डालने की पुष्टि कर सकता हूं। इसे एक आम अभिभावक निर्देशिका में डालकर मैं पुष्टि नहीं कर सकता।
— 9swampy
1
सभी समाधानों (TFS में) के लिए आम अभिभावक फ़ोल्डर में NuGet.Config कैसे डाल सकते हैं ताकि वे संदर्भित कर सकें? जिस तरह से मुझे पता है कि फ़ाइल के पास nuget.config हर समाधान के तहत .nuget फ़ोल्डर है; और यदि "रिपॉजिटरीपाथ वैल्यू = .पैकेज" है तो यह .nuget के तहत एक सबफ़ोल्डर बनाता है: C: \ TFS \ Comp \ Ent \ Sol \C \ NABuget \। यह भी स्वचालित TFS बिल्ड पर काम करना चाहिए। स्वीकृत उत्तर के लिए कुछ हाथ से काम करने की आवश्यकता होती है, साथ ही "रिपॉजिटरीपाथ मूल्य = $ \ .. \
— _ \ _ \ _"
2
विजुअल स्टूडियो 2015 और Nuget 3.4.3 के साथ काम करता है
— Hüseyin Yağlı
इतना ही नहीं यह पुराने पैकेज को तुरंत डिलीट कर देगा, यह HintPath को अधिलेखित और तोड़ देगा जिसे आपने csproj फ़ाइल में संभाला था। @ hB0 सही है। यह केवल अपेक्षाकृत सरल समाधानों के लिए काम करता है। एक बार जब आप शाखाओं, साझा परियोजनाओं आदि के साथ एक जटिल टीएफएस कार्यक्षेत्र संरचना में आते हैं, तो यह कुशलतापूर्वक पैमाने पर विफल हो जाता है।
— gravidThoughts
20

मेरे पास वीएस 2013 के साथ नूगेट संस्करण 2.8.50926 है। आपको कई नगेट.कॉन्फ़िग फ़ाइलों का उपयोग करने या जटिल निर्देशिका संरचनाओं का उपयोग करने की आवश्यकता नहीं है। बस यहां स्थित डिफ़ॉल्ट फ़ाइल को संशोधित करें:

%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 आपके द्वारा निर्दिष्ट नई, केंद्रीकृत निर्देशिका में स्वचालित रूप से लापता संकुल को पुनर्स्थापित करेगा।

— माथीउ
स्रोत
यह अब तक का सबसे आसान समाधान है और यह अधिक प्यार का हकदार है!
— कोरायम
2
यह आज वास्तव में सबसे आसान समाधान है लेकिन आपके उत्तर में एक चीज गायब है। आपको अभी भी प्रत्येक प्रोजेक्ट की csproj फ़ाइलों में हिंटपाथ से निपटने की आवश्यकता है। वे स्वचालित रूप से नए पथ पर लक्षित नहीं होंगे। क्या मैं सही हूँ?
— बैटमेसी
वास्तव में, मेरी कुछ पुरानी परियोजनाओं में कभी-कभी "पुराने" पैकेज फ़ोल्डर के संदर्भ होते हैं। हालांकि मेरे लिए सब कुछ सही ढंग से काम कर रहा है, इसलिए मुझे लगता है कि वैश्विक सेटिंग पूर्वता लेती है।
— मैथ्यू
OSX के लिए, docs.microsoft.com/en-us/nuget/consume-packages/… देखें । मैं नीचे mklink विचार पसंद करता हूं, भी।
— sgtz
8

पहले से ही nuget.targets को संशोधित करने की कोई आवश्यकता नहीं है। इसे nuget 2.8 ( http://nuget.codeplex.com/workitem/2921 ) में तय किया गया है । आपको केवल रिपॉजिटरीपथ सेट करने की आवश्यकता है।

— डैनियल
स्रोत
3

विजुअल स्टूडियो 2013 अपडेट 4 और नगेट पैकेज मैनेजर संस्करण> 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>

यह कारण होगा कि सभी पैकेज आपके nuget.config फ़ाइल के स्तर पर संकुल फ़ोल्डर में जाएंगे।

अब आप प्रत्येक के लिए जा सकते हैं। कमांड 'अपडेट-पैकेज-इंस्टालेशन' के साथ nset कंसोल।

यदि आपको एक ही स्तर पर कई रिपॉजिटरी पसंद हैं और उन सभी में एक ही पैकेज फ़ोल्डर को साझा करना है तो एक फ़ोल्डर को ऊपर जाने के लिए उपयोग करने का तरीका आज़माएं। 

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

लेकिन इस तरह से आपको लगता है कि nuget संकुल संदर्भ csproj आपके रिपॉजिटरी पथ के बाहर एक फ़ोल्डर को इंगित कर रहा है।

— जानूसज नोवाक
स्रोत
3

मैंने एक NuGet पैकेज तैयार किया है जो किसी प्रोजेक्ट में सभी NuGet संदर्भों को एक $ (SolutionDir) -relative फॉर्मेट में रूपांतरित करता है। यह बिल्ड-टाइम XSLT ट्रांसफ़ॉर्म का उपयोग करता है, इसलिए आपको अपनी प्रोजेक्ट फ़ाइल को हाथ से हैक करने की आवश्यकता नहीं है। आप अपने पैकेजों को स्वतंत्र रूप से अपडेट कर सकते हैं, यह कुछ भी नहीं तोड़ देगा।

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

या यदि आप Visual Studio 2015 Update 3 का उपयोग करते हैं, तो आप project.jsonयहाँ वर्णित के रूप में अपने पैकेज सन्दर्भों को माइग्रेट कर सकते हैं: https://oren.codes/2016/02/08/project-json-all-the-things

— ओलेग तारासोव
स्रोत
दुर्भाग्य से, ऐसा लगता है कि Microsoft Project.json से दूर जा रहा है । इसके अलावा, मुझे आपका नगेट पैकेज पसंद है। कुछ समय पहले मैंने NuGetReferenceHintPathRewrite का उपयोग किया था जो बहुत कुछ एक ही तरह से करता है, लेकिन अलग-अलग तरीके से
— Andrey Borisko
2

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/

— अमरनाथ चटर्जी
स्रोत
2

बस हार्डलिंक / पैकेज वांछित साझा स्थान पर। तब आपकी परियोजना अन्य उपयोगकर्ताओं के लिए नहीं तोड़ी जाएगी, जिनके पास एक विशेष पैकेज स्थान नहीं है।

व्यवस्थापक के रूप में एक कमांड प्रॉम्प्ट खोलें और उपयोग करें

mklink /prefix link_path Target_file/folder_path
— user803469
स्रोत
2

किसी भी महत्वपूर्ण समाधान के लिए, उपरोक्त उत्तर कम हो जाएंगे। काफी बस, एक अलग TFS कार्यक्षेत्र संरचना के साथ अलग-अलग रिश्तेदार पथ, शाखा, साझा परियोजनाएं आदि एक एकल केंद्रीय भंडार को असंभव बनाते हैं।

का उपयोग करना ($ सॉल्यूशनर) सही दिशा में एक कदम है, लेकिन ($ सॉल्यूशनडिर) कोडरोज फाइल को कोडिंग के साथ कोड बेस में काफी थकाऊ हो जाएगा जिसमें सैकड़ों पैकेज नियमित रूप से अपडेट किए जाते हैं (हर समय अपडेट होता है, हिंटपाथ के साथ ओवरराइट हो जाता है। एक नया रिश्तेदार पथ)। अगर आपको Update-Package -Reinstall चलाना है तो क्या होता है।

NugetReferenceHintPathRewrite नामक एक महान समाधान है । यह ($ SolutionDir) के इंजेक्शन को HintPaths में निर्माण करने से पहले (वास्तव में csproj फ़ाइल को बदले बिना) स्वचालित करता है। मुझे लगता है कि इसे आसानी से स्वचालित बिल्ड सिस्टम में शामिल किया जा सकता है

— gravidThoughts
स्रोत
1

पर उन लोगों के लिए एक संक्षिप्त सारांश वी.एस. 2013 पेशेवर साथ NuGet संस्करण: 2.8.60318.667

यह है कि आप पैकेज को .nuget फ़ोल्डर के सापेक्ष पथ पर कैसे निर्देशित करेंगे:

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

उदाहरण के लिए, यदि आपका समाधान (.sln फ़ाइल) C: \ Projects \ MySolution में रहता है, जब आप NuGet पैकेज को पुनर्स्थापित करने में सक्षम करते हैं, .nuget फ़ोल्डर को इस तरह बनाया जाता है: C: \ Projects \ MySolution.nuget और संकुल डाउनलोड हो जाएंगे। इस तरह एक निर्देशिका के लिए: सी: \ परियोजनाओं \ MySolution \ निर्भरता

नोट: कुछ (अज्ञात) कारण के लिए, हर बार जब मैं "रिपॉजिटरीपाठ" को अपडेट करता हूं, तो मुझे बदलावों को प्रभावी करने के लिए समाधान को बंद करना और फिर से खोलना होगा

— सुधांशु मिश्रा
स्रोत
ध्यान दें कि समापन कॉन्फ़िगरेशन टैग पर एक लापता स्लैश है।
— मू
— HANiS
0

अपने पैकेज मैनेजर के रूप में पाकेट का उपयोग करने वालों के लिए, आपकी निर्भरता फ़ाइल के लिए एक ऑटो-सिमलिंक विकल्प है:

storage: symlink

btw: पाकेट नगेट का लाभ उठाता है

संदर्भ: https://fsprojects.github.io/Paket/dependencies-file.html

यदि आप जितना संभव हो उतना कम संशोधित करना चाहते हैं, तो आप स्क्रिप्ट के साथ समय-समय पर उपनिर्देशिका को साफ कर सकते हैं। अर्थात। नुगेट का डिफ़ॉल्ट व्यवहार एक वैश्विक स्थान से फ़ाइलों को स्थानीय संकुल फ़ोल्डर में कॉपी करना है, इसलिए बाद में इन फ़ाइलों को हटा दें।

— sgtz
स्रोत
0

मैं सिर्फ NTFS जंक्शनों का उपयोग रिपॉजिटरी जड़ों के ऊपर एक एकल फ़ोल्डर के लिए सभी संकुल फ़ोल्डर को प्रत्यक्ष करने के लिए करता हूं। बहुत अच्छा काम करता है। समानांतर पैकेज के साथ कोई समस्या कई समाधानों में पुनर्स्थापित नहीं होती है। इसका एक फायदा यह है कि आपको अपने सोर्स कोड में कुछ भी फिर से कॉन्फ़िगर करने की आवश्यकता नहीं है, जैसे कि आपके .csproj फाइलों में सैकड़ों रिश्तेदार संकेत। यह फाइल सिस्टम को सिंगल पैकेज फ़ोल्डर के पुनर्निर्देशन और सिमुलेशन को संभालने से 'बस काम करता है'।

बस 'git' मुद्दों के लिए बाहर देखो। यद्यपि कमांड लाइन के माध्यम से 'git स्टेटस' कोई अस्थिर परिवर्तन नहीं दिखाता है, मैंने देखा कि GitKraken 'पैकेज' जंक्शन को एक अनस्टेज्ड फाइल के रूप में देखता है । यहां तक ​​कि जब आप इसे क्लिक करते हैं तो यह 'फ़ाइल एक निर्देशिका है' जैसी त्रुटियां दिखाता है। GitKraken भी इस 'फ़ाइल' को स्टेश करने की कोशिश करेगा यदि आप रिबास करते हैं, जंक्शन को नष्ट करते हैं, और इसे एक वास्तविक फ़ाइल के रूप में पुनर्स्थापित करते हैं जिसमें मूल फ़ाइल पथ के साथ पाठ होता है। बहुत ही अजीब व्यवहार। हो सकता है कि पैकेज फ़ाइल को अपने .gitignore में जोड़कर यह सुनिश्चित करने में सक्षम हो ।

— Triynko
स्रोत
-1

ये NuGet 2.1 के रूप में निर्देश हैं: http://docs.nuget.org/docs/release-notes/nuget-2.1

समाधान स्तर फ़ाइलों को संपादित करने की आवश्यकता नहीं है।

विजुअल स्टूडियो 2013 और तीन समाधान साझाकरण परियोजनाओं के साथ काम करता है।

समाधान स्तर NuGet (प्रत्येक nuget.exe इन .nuget फ़ोल्डर्स) को अपडेट करना न भूलें।

— user3285954
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.