विजुअल स्टूडियो समाधान के बीच आप बाहरी निर्भरताओं को कैसे साझा करते हैं?

Question

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

यहां मुख्य समस्या यह है कि मैं बड़े पैमाने पर समाधान उत्पन्न करता हूं और वे सभी एक ही तृतीय पक्ष डीएल पर निर्भर करते हैं। लेकिन मैं प्रत्येक समाधान के तहत प्रत्येक घटक की अलग प्रतियां बनाए रखना नहीं चाहता हूं। तो मुझे डीएल के उसी सेट के सभी अलग-अलग समाधानों को जोड़ने का एक तरीका चाहिए।

मुझे एहसास हुआ कि एक समाधान "लाइब्रेरी प्रोजेक्ट" में बाहरी पुस्तकालयों को शामिल करना हो सकता है जो सभी समाधानों में शामिल है और अन्य परियोजनाओं को उनके माध्यम से संदर्भित करने दें। (या बस सभी परियोजनाओं के लिए बाहरी डीएल के संदर्भ में सुनिश्चित करना सुनिश्चित करें।)

लेकिन क्या ऐसा करने के कोई बेहतर तरीके हैं? (पसंदीदा स्टूडियो के लिए कुछ प्रकार के प्लग-इन का उपयोग करना।)

मैंने Visual Studio Dependency Manager पर देखा है और यह एक सही मैच की तरह लगता है लेकिन किसी ने इसे वास्तविक के लिए आजमाया है? मैंने मेवेन के .NET बंदरगाहों को भी देखा है, लेकिन दुर्भाग्य से मैं उन लोगों की स्थिति से बहुत प्रभावित नहीं था। (लेकिन कृपया आगे बढ़ें और उन्हें सलाह दें कि अगर आपको लगता है कि मुझे उन्हें एक और प्रयास देना चाहिए।)

तो इस समस्या से निपटने का सबसे बढ़िया तरीका क्या होगा?

अद्यतन:

मुझे एहसास हुआ कि मैं समझाने के लिए मैं dll के के एक ही सेट को जोड़ने के साथ क्या मतलब की जरूरत है।

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

अद्यतन 2: ध्यान दें कि यह एक पुराने सवाल की तरह NuGet या OpenWrap अस्तित्व में उपकरण से पहले पूछा है। यदि कोई अधिक अद्यतित प्रदान करने के इच्छुक है, तो कृपया आगे बढ़ें और मैं स्वीकृत उत्तर बदल दूंगा।

Answer 1

1. असेंबली को स्टोर करने के लिए कुछ जगह खोजें। उदाहरण के लिए, मैं स्टोर करता हूं।इसलिए जैसे नेट कोर विधानसभाओं:

   • <branch> \ NetFX \ 2,0527 \ *
   • <branch> \ NetFX \ 3,0 \ *
   • <branch> \ NetFX \ 3,5 \ *
   • <branch> \ NetFX \ सिल्वरलाइट 2 \ *
   • <branch> \ नेटएफएक्स \ सिल्वरलाइट 3 \ *

2. अपनी परियोजनाओं को उपयुक्त पथों पर इंगित करने के लिए एमएसबिल्ड (या टीम बिल्ड में अतिरिक्त रेफरेंसपैथ) में संदर्भपैथ संपत्ति का उपयोग करें। सादगी और आसान रखरखाव के लिए, मेरे पास 1 *। लक्ष्य फ़ाइल है जो ऐसी प्रत्येक निर्देशिका के बारे में जानता है; मेरी सभी परियोजनाएं उस फ़ाइल को आयात करें।

3. सुनिश्चित करें कि आपकी संस्करण नियंत्रण रणनीति (शाखाकरण, विलय, स्थानीय < -> सर्वर मैपिंग) आपकी परियोजनाओं के बीच सापेक्ष पथ रखती है & आपके संदर्भ पथ निरंतर।

संपादित

प्रश्न में अद्यतन के जवाब में, मुझे एक और कदम जोड़ने: सुनिश्चित

4) यकीन है कि हर परियोजना फ़ाइल में हर विधानसभा संदर्भ पूर्ण नेट मजबूत नाम का उपयोग करता और कुछ और नहीं।

बुरा:

<Reference Include="Microsoft.SqlServer.Smo"> 
    <SpecificVersion`>False</SpecificVersion> 
    <HintPath>..\..\..\..\..\..\..\Program Files (x86)\Microsoft SQL Server\100\Shared\Microsoft.SqlServer.Smo.dll</HintPath> 
</Reference> 

अच्छा:

<Reference Include="Microsoft.SqlServer.Smo, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" /> 

बाद प्रारूप के लाभ:

• एक सहयोगी विकास के वातावरण में एक HintPath का प्रयोग अनिवार्य रूप से स्थितियों को बढ़ावा मिलेगा, जहां "यह मेरे लिए काम करता है "लेकिन दूसरों को नहीं। खासकर अपने निर्माण सर्वर। यह आपको अपने संदर्भ पथ को सही करने के लिए मजबूर करता है या यह संकलित नहीं होगा।
• एक कमजोर नाम का उपयोग करके "डीएलएल नरक" की संभावना को आमंत्रित किया गया है। एक बार जब आप मजबूत नामों का उपयोग कर लेते हैं तो आपके संदर्भ पथ में एक ही असेंबली के एकाधिक संस्करणों के लिए सुरक्षित होना चाहिए क्योंकि लिंकर केवल उन मानकों को लोड करेगा जो प्रत्येक मानदंड से मेल खाते हैं। इसके अतिरिक्त, यदि आप स्थान पर कुछ असेंबली अपडेट करने का निर्णय लेते हैं (प्रतियां जोड़ने के बजाय), तो जब भी बग्स आने लगते हैं तो आपको के बजाय संकलन समय में किसी भी ब्रेकिंग परिवर्तन की अधिसूचना दी जाएगी।

Answer 2

मैं आमतौर पर Extrenal या आंतरिक निर्भरता के लिए स्रोत नियंत्रण पर एक अलग फ़ोल्डर संरचना है, और इन filders विधानसभाओं है अनुसार निर्माण करने के लिए या उदाहरण के लिए संस्करण संख्या

सार्वजनिक \ बाहरी \ पुस्तकालयों \ Nunit \ 2.6 \

या

लोक \ आंतरिक \ पुस्तकालयों \ लॉगर \ 5.4.312 \

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

Answer 3

क्या अन्य सभी को कह रहा है करने के लिए जोड़ा जा रहा है, यह मूल रूप से नीचे दो बातें करने के लिए आता है:

1. सुनिश्चित करें कि सभी डेवलपर्स बाहरी पुस्तकालयों
2. का एक ही संस्करण है सुनिश्चित करें कि सभी डेवलपर्स है बनाना बनाना एक ही स्थान पर स्थित बाहरी पुस्तकालय (कम से कम, स्रोत कोड के सापेक्ष)

रिचर्ड बर्ग बताते हैं, आप संदर्भपैथ और/या Additi का उपयोग कर सकते हैं # 2 हल करने में मदद करने के लिए onalReferencePath। यदि आप अपनी बिल्ड प्रक्रिया में एमएसबिल्ड का उपयोग कर रहे हैं (हमारे मामले में, हम एमएस टीम बिल्ड के बजाय क्रूज़ कंट्रोल का उपयोग कर रहे हैं), तो आप कमांड लाइन पर संदर्भपैथ भी पास कर सकते हैं। # 1 को हल करने के लिए, मुझे उपयोगी होने के लिए svn:externals मिला है (यदि आप एसवीएन का उपयोग कर रहे हैं)।

मैवेन के साथ मेरा अनुभव यह है कि यह ज्यादातर उद्देश्यों के लिए अधिक है।