संस्करण नियंत्रण में NuGet से संकुल में जाँच?

Question

NuGet से पहले, एक परियोजना पर उपयोग किए जाने वाले सभी बाहरी DLL में चेक-इन करने के लिए आम तौर पर 'सबसे अच्छा अभ्यास' स्वीकार किया गया था। आमतौर पर Libsया 3rdPartyनिर्देशिका में।

NuGet के साथ काम करते समय, क्या मैं packagesनिर्देशिका में चेक-इन करने वाला हूं , या क्या MSBuild के लिए नगेट फीड से आवश्यक पैकेजों को ऑटो डाउनलोड करने का कोई तरीका है?

Comments

इस बात का जवाब एक राय है। "बहिष्कृत / नहीं" शिविर का कहना है कि क्योंकि प्रदान की गई सुविधा सेट विकास के दौरान इसे आसान बनाती है और पैकेज रिपॉजिटरी (जैसे nuget.org) से खींचने के लिए निर्माण करती है, यह सिर्फ बिल्ड समय पर किया जा सकता है। "शामिल / हां" शिविर का कहना है कि कोड बिना पैकेज का निर्माण नहीं करेगा बाहरी भंडार अनुपलब्ध होना चाहिए। निर्णय लेने से पहले दोनों पक्षों को पढ़ें। इसे भी देखें: softwareengineering.stackexchange.com/questions/301547/…

— CJBS

Answer 1

नहीं

चूँकि यह सवाल पूछा गया था कि अब पैकेज को स्रोत नियंत्रण में लाने के बिना NuGet का उपयोग करने के लिए एक आसान वर्कफ़्लो है

अपने पैकेज मैनेजर कंसोल से आपको 'NuGetPowerTools' इंस्टॉल करने की आवश्यकता है :

Install-Package NuGetPowerTools

फिर पैक को पुनर्स्थापित करने के लिए अपनी परियोजनाओं को सक्षम करने के लिए आपको एक और कमांड चलाने की आवश्यकता है:

Enable-PackageRestore

अब आप संकुल फ़ोल्डर के बिना अपना कोड आधार बनाने के लिए तैयार हैं। पिछली कमांड ने आपकी परियोजना फाइलों को बदल दिया ताकि यदि पैकेज गायब हों तो वे स्वचालित रूप से डाउनलोड और जोड़े जा सकें।

स्रोत

स्रोत नियंत्रण के लिए पैकेज किए बिना NuGet का उपयोग करना

Comments

NuGet-1.6 के रूप में, अब आपको ऐसा करने के लिए NuGetPowerTools की आवश्यकता नहीं है। बस समाधान एक्सप्लोरर में समाधान पर राइट क्लिक करें और चुनें Enable NuGet Package Restore। डॉक्स देखें ।

— कालेब पेडरसन

हां, आपको नीचे .nuget फ़ोल्डर और फ़ाइलों की जांच करनी चाहिए।

— बजे

@Edward - दार्शनिक रूप से, आप स्रोत नियंत्रण में NuGet पैकेजों को शामिल क्यों नहीं करेंगे, यह देखते हुए कि वे निर्भरताएं हैं? स्रोत नियंत्रण में जाँच की गई एक निर्माण के लिए कोड का 100% पर्याप्त होना चाहिए। NuGet संकुल को शामिल न करके बाहरी निर्भरताएँ निर्मित की जाती हैं, जैसे। क्या होगा यदि पैकेज डाउनलोड स्थान बदलता है, या किसी विषम कारण के लिए यह अब उपलब्ध नहीं है, आदि या अधिक संभावना है कि क्या पैकेज में कुछ मामूली बदलाव है जो बाद में फिर से डाउनलोड किया गया है और यह बिल्ड को तोड़ता है? अगर परियोजना के निर्माण के लिए जरूरी सब कुछ स्रोत नियंत्रण में होता तो इसे टाला जाता।

— होवीकैंप

@ हाईविकैम्प मैं अधिक सहमत नहीं हो सका। मैं तर्क नहीं समझता। मैं चाहता हूं कि स्रोत नियंत्रण पूरी तरह से आत्म निहित प्रणाली हो। खासकर अगर परियोजना कुछ विरासत है और थोड़ी देर के लिए एक्सेस नहीं की जाती है। मैं वापस आना चाहता हूं और इसमें कोई संशोधन नहीं है। Nuget विफलता का एक एकल बिंदु है जो मुझे नहीं करना है।

— तेलेवियन

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

— कैस्पर लियोन नील्सन

Answer 2

हाँ। "संकुल" निर्देशिका को अपने "लिबास" निर्देशिका के समतुल्य मानें जिसका आपने अपने प्रश्न में उल्लेख किया था। यह वह दृष्टिकोण है जिसे मैं व्यक्तिगत रूप से अपनी ओएसएस परियोजनाओं के साथ लेता हूं।

हम उन विशेषताओं की जांच कर रहे हैं जो MSBuild को आवश्यक पैकेजों को ऑटो डाउनलोड करने की अनुमति देगा, लेकिन इसे लागू नहीं किया गया है (नुगेट 1.1 के रूप में)।

मुझे लगता है कि कुछ लोगों ने पहले से ही इस तरह की सुविधाओं को लागू किया होगा, लेकिन हमारी योजना यह है कि नूगेट 1.2 या 1.3 में उम्मीद के मुताबिक उस फीचर को बनाया जाए।

Comments

मैं निश्चित रूप से उस सुविधा को देखना चाहूंगा। यह अच्छा होगा कि एक सीआई सर्वर या देव पीसी के लिए आवश्यक रूप से खींचे गए पैकेजों को सक्षम किया जाए, ताकि आप थर्ड पार्टी DLL के साथ सोर्स कंट्रोल रिपॉजिटरी को ब्लोट करने से बच सकें।

— जॉन मिल्स

यदि दृश्य स्टूडियो में पैकेज मैनेजर और कमांड-लाइन टूल दोनों "पैकेज को रिपेयर कर सकते हैं" जो कि भयानक होगा।

— शॉन विल्सन

शायद इस उत्तर को हटाना / संपादित करना अच्छा होगा, अब यह अप्रचलित है

— लेक्स

@ समय का जवाब वर्तमान में नहीं है

— एडवर्ड वाइल्ड

यह उत्तर अभी भी चालू है। उन पैकेजों पर विचार करें जो वैश्विक भंडार में नहीं हैं (उन्हें सुधारने / डाउनलोड करने का कोई तरीका नहीं है)। IMHO यह संस्करण प्रणाली में संकुल को संग्रहीत करने के लिए अच्छा अभ्यास है।

— पावेल होडेक

Answer 3

यहां सभी उत्तरों के बावजूद, यह अभी भी एक सादा ओले का भयानक समाधान है कि आपके सभी निर्भरताएं "किसी प्रकार के" संस्करण नियंत्रण के तहत नहीं हैं।

GIT के लिए, इसका मतलब GIT-LFS होगा।

एनपीएम के साथ हालिया एपिसोड से पता चलता है कि क्यों: यदि आप जिस इंटरनेट रिपॉजिटरी पर निर्भर करते हैं, वह अनुपलब्ध है, आदि उपलब्ध नहीं हैं, तो ठीक है कि आप खराब हैं?

अब आप अपना सामान बनाने में सक्षम नहीं हैं - और इसलिए वितरित करने में सक्षम नहीं हैं।

Comments

यह बहुत अच्छी बात है। यहां तक ​​कि अगर हमारे पास अपना आंतरिक NuGet सर्वर है, तो क्या हम इस पर भरोसा कर सकते हैं कि निर्माण के दौरान हमेशा उपलब्ध रहें? इसके अलावा, कितनी बार हमारे पैकेज बदलते हैं कि हमें हमेशा हर बिल्ड के लिए एक नई कॉपी प्राप्त करने की आवश्यकता होगी?

— जोश पी।

npmटूट गया क्योंकि यह संकुल को प्रदर्शित नहीं करता था, यह वास्तव में उन्हें हटा दिया। नुगेट ऐसा नहीं करता है; यदि किसी भी बिंदु पर आप नुगेट का उपयोग नहीं कर सकते हैं तो कुछ बहुत गलत है। मुझे नहीं लगता है कि git में निर्भरता के एक समूह को संचय करना एक अच्छा समाधान है: बस अपनी निर्भरता को एक विशिष्ट संस्करण पर लॉक करें और आपके और इंटरनेट के बीच एक दर्पण है यदि यह आपके लिए मायने रखता है।

— दान

"नुगेट ऐसा नहीं करता है"। खैर हुदिलुहू आपने अभी-अभी एक ऐसे डोमेन के भविष्य के लिए वादे किए हैं जो पूरी तरह से आपके नियंत्रण से बाहर है। वास्तविक दुनिया में चीजें आपके नियंत्रण क्षेत्र से बाहर हैं, अच्छी तरह से वे आपके नियंत्रण क्षेत्र से बाहर हैं। यह NuGet, साथ ही Npm के लिए भी जाता है। इसके अलावा एक "दर्पण" का आपका विचार ठीक वही है जो मैं यहां प्रस्तावित करता हूं, लेकिन आपकी दुनिया में "दर्पण" किसी भी प्रकार के संस्करण नियंत्रित योजना द्वारा समर्थित नहीं है। फिर से आपने उस समस्या को हल नहीं किया है जिसे आपने निर्धारित किया है।

— कैस्पर लियोन नील्सन

Answer 4

प्रश्न पूछने के बाद, मैंने निम्नलिखित दृष्टिकोण में रखा है ताकि मुझे टॉपवेल पैकेज की निर्देशिका में जांच न करनी पड़े ।

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

Comments

यह काम करता है, लेकिन इन दिनों, बिल्ट-इन इनेबल्ड पैकेज रिस्टोर को इस्तेमाल करने के लिए सबसे अच्छा है

— स्कॉट विंस्टीन

Answer 5

मुझे एहसास हुआ कि वास्तविकता अलग थी जब यह प्रश्न मूल रूप से पोस्ट किया गया था और उत्तर दिया गया था, लेकिन सौभाग्य से उत्तर थोड़ा बदल गया। अब प्री-बिल्ड इवेंट का उपयोग करके MSBuild के माध्यम से निर्भरता डाउनलोड करने के लिए NuGet का उपयोग करना संभव है। आपको पैकेज फ़ोल्डर को अपने कोड रिपॉजिटरी में रखने की आवश्यकता नहीं है, सभी निर्भरताएं डाउनलोड की जाएंगी और / या बिल्ड पर अपडेट की जाएंगी। यह एक वर्कअराउंड हो सकता है, लेकिन यह काफी सभ्य दिखता है। विवरण के लिए निम्नलिखित ब्लॉग पोस्ट देखें: http://blog.davidebbo.com/2011/03/use-nuget-without-committing-packages.html

Comments

मैं तब तक उत्साहित था जब तक मुझे याद नहीं था कि यह निर्माण सर्वर को NuGet रिपॉजिटरी तक पहुंचने की आवश्यकता है, और यह एकमात्र ऐसी जगह नहीं है जहां मैंने काम किया है जहां बिल्ड सर्वर इंटरनेट नहीं देख सकता है। मैं अभी-अभी संकुल ट्री की जाँच करने जा रहा हूँ ...

— piers7

Answer 6

09/20/13 के अनुसार, "नगेट रिस्टोर" नामक कुछ है। यदि आप ऐसा करना चाहते हैं, तो आपको वास्तव में पैकेज फ़ोल्डर में जांच करने की आवश्यकता नहीं है। (खासकर यदि आप डीवीसीएस का उपयोग कर रहे हैं)

इसे देखें: स्रोत नियंत्रण http://docs.nuget.org/docs/workflows/use-nuget-without-committing-packages पर संकुल के आने के बिना NuGet का उपयोग करना

Answer 7

यह पोस्ट बहुत पुरानी हो गई है। जवाब अभी भी नहीं है, लेकिन समाधान बदल गया है। NuGet 2.7+ के रूप में आप अपने स्रोत में NuGet.exe फ़ाइल को शामिल किए बिना स्वचालित पैकेज पुनर्स्थापना सक्षम कर सकते हैं (यह कम से कम कहने के लिए अवांछनीय है) और यदि आप किसी भी आधुनिक DVCS का उपयोग करते हैं, तो आप संकुल फ़ोल्डर को अनदेखा कर सकते हैं। यदि आपको किसी विशेष अनुकूलन की आवश्यकता है तो आप समाधान रूट में एक nuget.config फ़ाइल बना सकते हैं।

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

इसके अलावा, नए csproj प्रारूप के साथ आप अतिरिक्त nuget.config फ़ाइलों से बच सकते हैं और साथ ही अब एकीकृत है। कृपया इस पोस्ट को देखें जो यह बताता है कि बेहतर:

.Nuget फ़ोल्डर को संस्करण नियंत्रण में जोड़ा जाना चाहिए?