2013-02-05 37 views
9

में निर्भरता प्रबंधन कैसे करें इस विषय पर कई पोस्ट हैं, लेकिन मुझे अभी तक "असली" समाधान नहीं मिला है।विजुअल स्टूडियो/एमएसबिल्ड

अपने पेड़ निर्भरता का प्रबंधन कैसे करता है (दोनों समय और क्रम संकलन) (परियोजना और फ़ाइल संदर्भ के माध्यम से अर्थात दृश्य स्टूडियो परियोजना फ़ाइलें) MSBuild परियोजना फ़ाइलों का उपयोग कर?

यह अच्छी तरह से ज्ञात है कि यदि कोई रनटाइम निर्भरता नहीं है, और यहां तक ​​कि कॉपी-लोकल = सत्य भी है, तो बाल परियोजनाओं से परियोजना संदर्भों को प्रतिलिपि समय संदर्भ में कॉपी नहीं किया जाएगा। इसलिए, किसी भी कमजोर युग्मित घटक की प्रतिलिपि नहीं बनाई जाएगी।

इस समस्या को हल करने के लिए हैक कॉपी-स्थानीय = सच के साथ माता-पिता इस परियोजना में शामिल करने के लिए निर्भरता है। हालांकि, यह मूल रूप से आपके निर्भरता पेड़ को नष्ट कर देता है क्योंकि आप अब नहीं जानते कि निर्भरता कहां है और आखिरकार, जब आपका ऐप बढ़ता है और मोर्फ़ होता है, तो आप डीएलएल नरक के संस्करण के साथ समाप्त होते हैं। आपकी मूल परियोजना 10 से 100 के डीएलएस के साथ समाप्त होती है, जिनमें से अधिकांश बाल परियोजनाओं में डीएलएस की रनटाइम निर्भरताएं होती हैं। http://blog.alexyakunin.com/2009/09/making-msbuild-visual-studio-to.html:

एक और हैक एक कस्टम लक्ष्य फ़ाइल लिख सकते हैं और यह हर परियोजना फ़ाइल से फोन करने के लिए है। लेकिन निश्चित रूप से एक बेहतर विकल्प है। यह इतनी रोटी और मक्खन चीज है। जावा देवों को कभी भी इस तरह के मामूली मुद्दों से निपटना नहीं है।

मैं क्या इकट्ठा कर सकते हैं से, इस समस्या को हल करने के लिए Microsoft तरह से हर देव, परीक्षण और उत्पादन मशीन के लिए GAC में हर निर्भरता रजिस्टर करने के लिए है। लेकिन यह बेवकूफ और कष्टप्रद है। मैं इस विकल्प और शिक्षित खंडन देने से परेशान नहीं होगा।

GAC विकल्प से बचना, एक MSBuild कैसे इस्तेमाल कर सकते हैं एक निर्भरता वृक्ष है जो रनटाइम केवल निर्भरता भी शामिल प्रबंधन करने के लिए? माइक्रोसॉफ्ट यह कैसे करता है? निश्चित रूप से वे उपरोक्त लिंक में से एक जैसे कस्टम लक्ष्य फ़ाइलों को नहीं चलाते हैं।

मुझे उम्मीद है कि किसी एंटरप्राइज़ से .NET पृष्ठभूमि बढ़ सकती है और इस पर कुछ वास्तविक सलाह दे सकती है। अन्यथा मुझे NANT (shudder) में मेरी सभी बिल्ड स्क्रिप्ट को फिर से लिखना होगा।

धन्यवाद सब।

अद्यतन

कुछ टिप्पणियों के जवाब में, निम्नलिखित मेरे वर्तमान परियोजना से इस मुद्दे का एक व्यावहारिक उदाहरण है।

अनुप्रयोग एक वेब अनुप्रयोग परियोजना है कि WCF सेवाओं का एक सूट को उजागर करता है। इसमें एक बाहरी डोमेन डीएलएल है जिसमें बाह्य सेवा वर्ग और एक आंतरिक डोमेन डीएलएल है जिसमें आंतरिक सेवा पीओसीओ, डोमेन ऑब्जेक्ट्स और डीएओ शामिल हैं। सभी आंतरिक डोमेन वर्गों के लिए इंटरफेस (डीटीओ) युक्त एक अलग एकीकरण डीएलएल है जो हमें बाहरी और आंतरिक डोमेन को पूरी तरह से कम करने की अनुमति देता है। पूरी बात Spring.net के साथ वायर्ड है। मुझे उम्मीद है कि यह स्पष्ट है, अगर आपको और स्पष्टीकरण की आवश्यकता है तो मुझे बताएं।

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

तो वेब एप्लिकेशन में बाहरी डोमेन डीएलएल का संदर्भ होता है जिसमें आंतरिक डोमेन डीएलएल का संदर्भ होता है जिसमें तृतीय पक्ष पुस्तकालयों और तृतीय पक्ष पुस्तकालयों द्वारा आवश्यक विभिन्न अप्रत्यक्ष और कमजोर युग्मित निर्भरताओं के कई संदर्भ शामिल हैं।

समस्या तब होती है जब आंतरिक डोमेन DLL में तृतीय पक्ष निर्भरता होती है। oracle.dataaccess जिसे रनटाइम पर NHibernate द्वारा आवश्यक है। यहां तक ​​कि जब मैं इन DLLs पर 'copy-always = true' सेट करता हूं, तब भी उन्हें वेब ऐप पैकेज में कॉपी नहीं किया जाता है। पैकेज में उन्हें शामिल करने का एकमात्र तरीका यह है कि इन डीएलएल को वेब ऐप के संदर्भों में जोड़ना है। मैं ऐसा नहीं करना चाहता क्योंकि अब मेरे पास सार्थक निर्भरता वृक्ष नहीं है।

मुझे आशा है कि इससे समस्या स्पष्ट हो जाएगी। अगर कुछ अस्पष्ट है तो कृपया मुझे बताएं। इस तरह की चीजों का वर्णन करना मुश्किल है।

यदि किसी को भी एक ही समस्या है, तो कृपया बोलें और अपना अनुभव साझा करें।

+0

हाँ मैं आपसे सहमत हूं कि उन्हें जीएसी में जोड़ना अक्षम होगा, लेकिन मैं सिर्फ उत्सुक था कि इस मामले में NAnt आपको और कैसे मदद करेगा? इसके अलावा जावा विकास में इस परिस्थितियों को कैसे संभाला जाएगा? मैं अधिक सुराग के लिए कोशिश कर रहा हूँ ताकि मैं आप बेहतर जवाब दे सकते हैं ... आप –

+0

धन्यवाद मैं वह जावा में Maven की तरह कुछ चाहता है। असल में मैं कुछ भी इसी तरह की तलाश में हूं। http://maven.apache.org/ –

+0

प्रतिबिंब में, मुझे लगता है कि NANT अधिक समस्याएं पैदा करेगा। मैं मूल पोस्ट को समस्या के एक विशिष्ट उदाहरण के साथ अपडेट करूंगा। –

उत्तर

3

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

  1. के रूप में आपने कहा था ऐसा करने के लिए सबसे आसान काम आपकी निर्भरता के सभी के साथ एक अलग फ़ोल्डर की स्थापना की और लक्ष्य फ़ाइल है कि उन्हें अपने बिन फ़ोल्डर में कॉपी करेंगे तैयार करना है। यदि आपके पास ऐसी निर्भरताएं हैं जो अक्सर बदल नहीं रही हैं जो काम कर सकती हैं। अगर आपकी कंपनी की एक और टीम उन्हें बना रही है और वे अक्सर बदलती हैं, तो यह दृष्टिकोण अच्छा नहीं है।

  2. एक और सरल दृष्टिकोण - यदि आप अपने समाधान से अपनी निर्भरताओं का संदर्भ दे रहे हैं तो आप केवल बिल्ड पथ बदल सकते हैं, ताकि वे सीधे आपके मुख्य प्रोजेक्ट के बिन फ़ोल्डर में निर्माण कर सकें। इस तरह आपको उन्हें सीधे संदर्भित करने की आवश्यकता नहीं है।

  3. NuGet का उपयोग करें। आप इसे स्थानीय NuGet भंडार की स्थापना की और है कि http://juristr.com/blog/2012/04/using-nuget-to-distribute-our-company/

मुझे आशा है कि मदद करता है के लिए उपयोग करने के लिए एक अर्थपूर्ण हो सकता है एक अलग शिथिल युग्मित निर्भरता उत्पादन टीम है।