2009-11-09 4 views
8

में परियोजना संदर्भ के बजाय डीएल संदर्भ द्वारा .NET असेंबली निर्भरताओं का प्रबंधन करना हमारे पास एक .NET प्रोजेक्ट है जिसमें एकाधिक सबप्रोजेक्ट्स (लगभग 20) शामिल हैं। कई समाधान हैं, जिनमें से प्रत्येक केवल उन सबप्रोजेक्ट्स हैं जो विशेष समाधान के लिए प्रासंगिक हैं।वीएस

मनमाने ढंग से समाधान की अनुमति देने के लिए, हमारे सबप्रोजेक्ट्स परियोजना संदर्भों के माध्यम से एक दूसरे का संदर्भ नहीं देते हैं, बल्कि प्रत्यक्ष डीएल संदर्भों के माध्यम से। HintPath को $ (कॉन्फ़िगरेशन) बनाने के लिए csproj फ़ाइल का थोड़ा tweaking है, इसलिए डीबग संदर्भ डीबग डीएलएस बनाता है और रिलीज संदर्भ रिलीज डीएलएस बनाता है।

सभी अच्छा काम करता है, लेकिन वहाँ दो प्रमुख समस्याएं हैं - एक कष्टप्रद है और एक अन्य वास्तव में तीव्र है:

  1. वी.एस. निर्भरता गणना के प्रयोजन के लिए dll संदर्भ को नहीं पहचानता। जब भी कोई नई परियोजना या संदर्भ जोड़ा जाता है, तो हमें "परियोजना निर्भरता" संवाद का उपयोग करके निर्भरताओं को मैन्युअल रूप से निर्दिष्ट करना होगा। यह कष्टप्रद है।
  2. हम न तो रिशेर्पर और न ही विजुअल असिस्ट का उपयोग करते हैं (महान उपकरण, लेकिन हम उनका उपयोग नहीं करते हैं, यह एक दिया गया है)। हम मानक "ब्राउज़ टू डेफिनिशन" कमांड का उपयोग करना चाहते हैं (उदाहरण के लिए, स्रोत कोड पर संदर्भ मेनू से उपलब्ध)। गंभीर समस्या यह है कि यह केवल क्रॉस प्रोजेक्ट का काम करता है यदि एक प्रोजेक्ट प्रोजेक्ट संदर्भ का उपयोग करके दूसरे का संदर्भ देता है और यह संदर्भ तब नहीं होता है जब संदर्भ प्रत्यक्ष डीएल संदर्भ, होता है भले ही संदर्भित प्रोजेक्ट समाधान में शामिल किया गया हो! यह एक वास्तविक बमर है, क्योंकि स्रोत पर नेविगेट करने के बजाय यह मेटाडेटा में जाता है।

मैं उन लोगों की सलाह ले रहा हूं जो हमारे जैसे डीएल संदर्भों का उपयोग करते हैं और इन दोनों मुद्दों को किसी तरह से दूर करते हैं। धन्यवाद।

संपादित करें:

ध्यान दें, कि "परिभाषा करने के लिए ब्राउज़ करें" मुद्दा के अलावा, परियोजना के संदर्भ के बजाय Dll संदर्भ होने परियोजना प्रबंधक पर केवल एक बार लागत आती - प्रत्येक की परियोजना निर्भरता अद्यतन करने के लिए है जो प्रभावित समाधान जब एक नई परियोजना को जोड़ा जाता है या एक नई निर्भरता पेश की जानी चाहिए। इन परियोजना निर्भरताओं को .sln फ़ाइल में रखा जाता है और किसी भी प्रोजेक्ट की आवश्यकता नहीं होती है जब तक कोई नई प्रोजेक्ट नहीं आती है या एक नई निर्भरता बनाई जाती है, जो अक्सर ऐसा नहीं होता है।

हम सीआई सर्वर पर हमारी परियोजनाओं के निर्माण के लिए एमएसबिल्ड का उपयोग कर रहे हैं, जो वीएस के समान एसएसएन फाइलों का उपयोग करता है। एक मुख्य। एसएलएन फ़ाइल है, जिसमें सभी सबप्रोजेक्ट शामिल हैं।

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

+0

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

+0

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

+0

हाँ, मुझे उससे भी नफरत है। एक समाधान वास्तव में महान होगा। –

उत्तर

2

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

+0

लोड प्रोजेक्ट जितना अधिक प्रोजेक्ट करता है, साथ ही यह निर्माण करते समय सभी परियोजनाओं की जांच करता है और यदि बड़ा हिस्सा अपरिवर्तित है तो यह ओवरहेड का बहुत अधिक है। एक यूआई डेवलपर कभी भी परियोजनाओं के आधे हिस्से को छू नहीं सकता है, तो हर बिल्डिंग लागत का भुगतान क्यों करें, साथ ही समाधान लोड करने की एक बार लागत? – mark

-1

ऐसा लगता है कि आप जिन समस्याओं का सामना कर रहे हैं, वे आपके टूल सेट को गलत तरीके से उपयोग करने का प्रत्यक्ष परिणाम हैं। जब आप इसे प्रबंधक नहीं देते हैं तो विजुअल स्टूडियो का स्वचालित रूप से प्रोजेक्ट निर्भरताओं की गणना करने का कोई अन्य तरीका नहीं है।

ऐसा लगता है कि आपके पास दो विकल्प हैं।

  1. उपयोग परियोजना निर्भरता
  2. उपयोग अन्य निर्माण प्रणाली (NAnt की तरह) का प्रबंधन करने के दृश्य स्टूडियो

ऐसा लगता है कि आप की संभावना से इनकार किए जाने का विकल्प # 1, तो मैं किसी भी अधिक का पता है कि नहीं होगा । तो केवल विकल्प # 2 छोड़ देता है।

आप अपनी व्यक्तिगत सीएसप्रोजे परियोजनाओं के निर्माण के लिए NAnt का उपयोग कर सकते हैं और परियोजनाओं के बीच निर्भरताओं को परिभाषित करने के लिए अपनी एनएएनटी बिल्ड स्क्रिप्ट का उपयोग कर सकते हैं। इसके लिए दो डाउनसाइड्स हैं।

  1. आप यह सब प्रबंधन करने के लिए हाथ (जो यह लग रहा है कि आप की तरह करने के लिए तैयार कर रहे हैं) के रूप में आप के लिए टूट जैसा कि अभी है
  2. दृश्य स्टूडियो समान रूप से होगा खरीदते हैं।

डाउनसाइड # 2 पर, विजुअल स्टूडियो पूरी तरह से आपके समाधान को संकलित करने में सक्षम नहीं होगा क्योंकि वह तर्क VS से बाहर और बाहरी निर्माण स्क्रिप्ट में स्थानांतरित कर दिया गया होगा। इससे डेवलपर्स के बीच भ्रम पैदा हो सकता है, और डीबगिंग प्रक्रिया में बाधा आती है। यह नहीं कह रहा कि उन चीजों को दूर करने में सक्षम नहीं है ... बस यह कह रहा है कि विकास प्रक्रिया के उन चरणों में यह अतिरिक्त सेटअप शामिल होगा।

+0

मुझे समझ में नहीं आता कि नंत मुझे एमएसबिल्ड के विरोध में क्या देता है। हमारी परियोजनाएं सीआई सर्वर पर एमएसबिल्ड के साथ बनाई गई हैं और यह बहुत अच्छी तरह से काम करती है। एकमात्र समस्या यह है कि .sln फ़ाइलें (जिनका उपयोग msbuild के साथ-साथ वीएस द्वारा किया जाता है) में परियोजना निर्भरताओं को स्पष्ट रूप से शामिल करना चाहिए, क्योंकि हम परियोजनाओं के बजाय डीएलएस का संदर्भ देते हैं। बस इतना ही। मैं नहीं देखता कि मुझे NANT पर क्यों जाना चाहिए। – mark

+0

उत्तर के लिए धन्यवाद। मैंने अपना प्रश्न संपादित कर लिया है। – mark

7

आपकी बिल्ड कॉन्फ़िगरेशन के साथ समस्या निम्न है: कहें कि आपके पास 3 प्रोजेक्ट और 2 समाधान हैं।

Solution1 
- Project1 
- Project2 
Solution2 
- Project1 
- Project3 

अचानक, Solution2 निर्माण solution1 के लिए कोड की हिस्सा बनाता है, एक अमान्य स्थिति में इसे छोड़ने (नवीनतम बाइनरी या तो असंगत हैं या निर्मित होने की जरूरत नहीं थी)।

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

संक्षेप में, आप कुछ समय लगेगा और अपने समाधान पुनर्गठन निम्न शर्तों को पूरा करने के लिए करना चाहिए:

  • हर परियोजना वास्तव में एक ही समाधान में शामिल है।
  • यदि कोई प्रोजेक्ट एक ही समाधान के भीतर किसी अन्य प्रोजेक्ट पर निर्भर करता है, तो इसे एक परियोजना संदर्भ बनाएं।
  • यदि कोई परियोजना किसी अन्य प्रोजेक्ट पर विभिन्न समाधान पर निर्भर करती है, तो इसे एक डीएलएल संदर्भ बनाएं।

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

Solution1 
- Project1 
- Project2 -> reference project Project1 
Solution2 
- Project3 -> reference Project1.dll 

इस मामले में, आप Externals\Project1\Debug और Externals\Project1\Release में Project1.dll और Project1.pdb की प्रतियां रखें, और Project3 में External\Project1\$(Configuration)\Project1.dll संदर्भ चाहते हैं। जब आप अपने सभी अन्य समाधानों को बनाने के लिए तैयार हों तो केवल बाहरी निर्देशिका में बिल्ड अपडेट करें।

+0

उत्तर के लिए धन्यवाद। मैंने अपना प्रश्न संपादित कर लिया है। – mark

+0

ठीक है, grt सलाह। उपरोक्त में जोड़ना: प्रकाशित Project.dll के लिए संस्करण नियंत्रण का प्रबंधन कैसे करें? मुझे उम्मीद है कि प्रोजेक्ट 3 संस्करण नियंत्रण से Project1.dll चुनता है। –