UPD: यहां जिस तरह का प्रयोग किया जाता है वैसा ही एक तरीका NuGet 1.6 के साथ शामिल है। तदनुसार, लेख पुराना है।
जावा के बारे में मुझे जो चीजें पसंद हैं उनमें से एक है मावेन। आपकी ज़रूरत की सभी चीज़ों की सूची में एक फ़ाइल, और रिपॉजिटरी में कोई बायनेरी नहीं। जब नुपैक दिखाई दिया, तो मैंने फैसला किया - तूफान, यहाँ यह है, खुशी हमारी सड़क पर आई। लेकिन यह वहाँ नहीं था। NuPack ने पैकेज के साथ काम करने के लिए एक सुविधाजनक इंटरफ़ेस प्रदान किया ... लेकिन निर्माण प्रक्रिया में सामान्य रूप से पेंच करने की क्षमता के बिना।
मैंने इसे देखा, फिर देखा, लेकिन मुझे कोई वास्तविक लाभ नहीं मिला। यह मैनुअल पॉवरशेल कमांड के नाम से पैकेज डाउनलोड करने में बहुत मदद नहीं करता है। ठीक है, हाँ, यह जहाँ से FIG को डाउनलोड करने और यहाँ तक कि अपने हाथों से संदर्भ जोड़ने की तुलना में अधिक सुविधाजनक है, लेकिन मुझे हर दिन इसकी आवश्यकता नहीं है। सामान्य तौर पर, खेल मोमबत्ती के लायक नहीं है।
लेकिन एक दिन मुझे एहसास हुआ कि मुझे अपने एक्सेस कंट्रोल में Shared \ Bin फ़ोल्डर के साथ कुछ करने की ज़रूरत है, क्योंकि यह पहले से ही अविश्वसनीय रूप से सूज गया था। मैंने यह देखने का फैसला किया कि क्या नुपैक के साथ कुछ बदल गया है, जिसे पहले से ही नुगेट कहा जाता था। नहीं,
गाड़ियां और वहां ।
लेकिन nuget.exe में एक दिलचस्प विशेषता है ...
यदि आप फ़ाइल "package.config" को एक पैरामीटर के रूप में पास करते हैं, जिसमें NuGet इस परियोजना में स्थापित संकुल की एक सूची संग्रहीत करता है, तो वह इसमें निर्दिष्ट सभी संकुल को डाउनलोड करेगा!
तकनीक का मामला
1) हम NuGet.Targets बनाते हैं, जिसे हम अपनी परियोजनाओं में शामिल करेंगे:
<? xml version ="1.0" ? >
< Project xmlns ="http://schemas.microsoft.com/developer/msbuild/2003" >
< PropertyGroup >
< BuildDependsOn >
_InsallNuGetPackages;$(BuildDependsOn)
</ BuildDependsOn >
</ PropertyGroup >
< Target Name ="_InsallNuGetPackages" >
< Exec Command ="$(MSBuildThisFileDirectory)\NuGet install $(ProjectDir)packages.config -o $(SolutionDir)Packages" />
</ Target >
</ Project >
* This source code was highlighted with Source Code Highlighter .
हम इसे नियंत्रण में रखते हैं, प्रत्येक निर्माण से पहले यह NuGet चलेगा। नुगेट की नियुक्ति के बारे में: आप एक्स-बॉक्स को लक्ष्य के बगल में नियंत्रण में रख सकते हैं, आप इसे केवल पथ में जोड़ सकते हैं। मेरे लिए पहला विकल्प, अधिक सुविधाजनक है, हालांकि कम कोषेर। यदि आप सभी कर्मचारियों को Nuget.exe को पाथ में डालने के लिए बाध्य करना पसंद करते हैं - बस
$(MSBuildThisFileDirectory)
हटा दें।
... बिल्ड सर्वर के बारे में मत भूलना;)
2) NuGet प्रोजेक्ट में पैकेज जोड़ें।
3) * * प्रोज-फाइल में हाथ जोड़ें:
< Import Project ="$(SolutionDir)\\\\\NuGet.Targets" />
* This source code was highlighted with Source Code Highlighter .
दरअसल, बिल्डिंग बनाते समय सभी पैकेज अपने आप खींच लिए जाएंगे। और केवल अगर वे अभी तक वहां नहीं हैं - जो अच्छा है।
क्या होगा अगर ...
... मेरी परियोजना बायनेरिज़ का उपयोग करती है जो nuget.org पर नहीं है? समस्या नहीं है। अपना फ़ीड बनाएं। आप
MyGet का उपयोग कर सकते हैं, लेकिन मेरी
राय में , अपने सर्वर पर बनाना और भी आसान है:
1) एक नया खाली वेब एप्लिकेशन प्रोजेक्ट बनाएं
2) हम इसे NuGet.Server पैकेज पर रखते हैं
३) सार्वजनिक।
सब कुछ तैयार है। आप इसे थोड़ा साफ कर सकते हैं, क्योंकि कचरा प्रकाशित होता है ... खैर, हमेशा की तरह। प्रकाशित परियोजना में, एक पैकेज फ़ोल्डर होगा, जहां हम वास्तव में अपने पैकेज डालते हैं।
कुकिंग गार्निश पैकेज।
यह भी आसान है। आपकी मदद करने के लिए nuget.exe।
बदले में:
1)
nuget spec .
एक
nuget spec .
फ़ाइल उत्पन्न
nuget spec .
जिसमें पैकेज मेनिफ़ेस्ट टेम्पलेट होगा। हम सही करते हैं, यह तुच्छ है, आप इसे स्वयं समझ लेंगे :)
2) एक खाली डैडी में हमारे nuspec रखो, इसके बगल में एक lib बनाएं, इसमें अपना dll डालें।
nuget pack ..nuspec
चलाएं, जो पैकेज फ़ाइल उत्पन्न करेगा।
3) उपरोक्त पैकेज फ़ोल्डर में, सर्वर पर प्राप्त पैकेज डालो।
डैडी लिब के बारे में: इसमें पाई गई फाइलों को इंपोर्टिंग प्रोजेक्ट में रेफरेंस में जोड़ा जाएगा। और बस ऐसे ही। यह दस्तावेज़ में स्पष्ट रूप से वर्णित नहीं था, इसलिए मुझे प्रयोग करने की आवश्यकता थी।
स्पर्श का समापन
इसलिए, हमारे पास तैयार पैकेज के साथ एक सर्वर है, हमें इसे स्टूडियो में बांधने और प्रक्रिया का निर्माण करने की आवश्यकता है। स्टूडियो में - फिर से, कोई समस्या नहीं:
टूल्स-> लाइब्रेरी पैकेज मैनेजर-> पैकेज मैनेजर सेटिंग्स, पैकेज सोर्स चुनें, अपना जोड़ें। लेकिन मैं वास्तव में क्या हूं - यदि आप पहले से ही इस जगह पर पढ़ चुके हैं, तो आप इसका पता लगा लेंगे।
निर्माण प्रक्रिया: ईमानदार होने के लिए, मुझे उम्मीद थी कि NuGet पैकेज फ़ाइलों से पैकेज पथ को संग्रहीत करेगा। लेकिन नहीं, वह ऐसी तिकड़मों में नहीं पड़ता। मुझे nuget.exe के लिए पैरामीटर जोड़ना होगा ... याद रखें, मैंने इसे एक अलग फाइल में चलाया है? एक पंक्ति के लिए बहुत सम्मान, है ना? नहीं, सच नहीं है। अब यह हमारे लिए उपयोगी है (क्योंकि यह मेरे लिए 30 अलग-अलग परियोजनाओं पर नहीं चढ़ने के लिए काम आया)। लाइन को निष्पादन से निम्नलिखित में बदलें:
< Exec Command ="NuGet install $(ProjectDir)packages.config -o $(SolutionDir)Packages -Source nuget.example.com/nuget -Source go.microsoft.com/fwlink/?LinkID=206669" />
* This source code was highlighted with Source Code Highlighter .
स्रोतों का क्रम वास्तव में यह है - जिस स्थिति में आधिकारिक भंडार से कुछ संस्करण को अपने स्वयं के पैच के साथ बदलना संभव होगा (उदाहरण के लिए, मेरे पास यह AjaxControlToolkit के साथ है)।
... बधाई, अब आप सुरक्षित रूप से साझा किए गए \ बिन राक्षस को हटा सकते हैं, प्रतिबद्ध कर सकते हैं और सॉर्ट कंट्रोल में स्वच्छता का आनंद ले सकते हैं।