2010-07-03 23 views
14

यह शायद एक बेवकूफ सवाल की तरह लगता है, लेकिन मैं इसे एक शॉट देने जा रहा हूं।असेंबली स्तर पर विजुअल स्टूडियो में परिपत्र निर्भरता को सक्षम करना संभव है? पारस्परिक रूप से निर्भर असेंबली भी संभव हो सकता है?

तो दृश्य स्टूडियो में, आप दो परियोजनाओं एक्स नहीं हो सकता है और वाई एक्स संदर्भ Y और Y संदर्भ एक्स

सामान्य तौर पर, मैं पूरी तरह समझ सकते हैं कि कैसे एक सर्कुलर निर्भरता होने समस्याएं खड़ी कर सकता के लिए कई कारणों से।

लेकिन क्या यह वास्तव दो परियोजनाओं कि इस तरह से अन्योन्याश्रित हैं संकलित करने के लिए संभव नहीं है? ऐसा लगता है कि यह संभव होना चाहिए, क्योंकि (मेरे दिमाग में - शायद मैं पूरी तरह से इस आधार पर ऑफ-बेस) दो पारस्परिक रूप से निर्भर असेंबली वास्तव में नहीं है इसलिए दो पारस्परिक रूप से निर्भर वर्गों से अलग है - एक मामला जो कानूनी और संकलित किया जा सकता है।

यदि आपने कहा, "दो असेंबली एक दूसरे पर निर्भर नहीं हो सकते हैं क्योंकि संकलक एक दूसरे से पहले संकलित नहीं कर सकता"; सिवाय इसके कि ऐसा लगता है कि आप एक ही असेंबली के भीतर दो वर्गों के लिए एक ही तर्क कर सकते हैं, और स्पष्ट रूप से संकलक इस परिदृश्य से ठीक हो सकता है।

मूल रूप से मैं जो कारण पूछ रहा हूं वह यह नहीं है कि मुझे ऐसा करने की कुछ हताश इच्छा है जो मुझे पता है कि आम तौर पर मुझे सलाह दी जाती है। विशेष रूप से मैं सोच रहा हूं क्योंकि यह अच्छा होगा अगर मेरे पास दो परियोजनाएं हो सकती हैं - कहें, MyProjectCS और MyProjectVB - जो कि मूल रूप से एक इकाई के दो पारस्परिक रूप से निर्भर भागों के रूप में मौजूद थे, और केवल अलग थे क्योंकि कुछ हिस्सों को सी # में लिखा गया था और अन्य भागों VB.NET में लिखे गए थे।

  1. यह इस व्यवहार को सक्षम करना संभव है (दृश्य स्टूडियो में, या कहीं और, उस बात के लिए):

    तो, मेरे सवाल (ओह, तीन गुना) क्या है?

  2. यदि यह किसी भी आईडीई के भीतर संभव नहीं है, तो यह कम से कम सैद्धांतिक रूप से संभव है, या पारस्परिक रूप से निर्भर असेंबली संभवतः मौजूद नहीं हो सकता है?
  3. यदि यह सैद्धांतिक रूप से भी संभव नहीं है, तो क्यों नहीं? दूसरे शब्दों में, पारस्परिक रूप से निर्भर असेंबली एक असेंबली के भीतर पारस्परिक रूप से निर्भर कोड से अलग कैसे हैं?
+7

यह हर समय मेरे साथ होता है ... मेरी अंडे परियोजना 'चिकन.dll नहीं मिली ...' जबकि मेरी चिकन परियोजना एक समान त्रुटि फेंकता है। उबाऊ। –

+2

.NET ढांचा आंतरिक रूप से पारस्परिक रूप से निर्भर असेंबली का उपयोग करता है। किसी ने कुछ समय पहले .NET असेंबली को अलग करने के बाद पाया और SO पर उस प्रश्न को देखा (हालांकि लिंक नहीं मिल सकता है)। – Alex

+0

@ एलेक्स हाँ मैंने एक बार पाया। यह मुझे देखा जैसे यह प्रतिबिंब के माध्यम से किया था। – Joshua

उत्तर

11

मौजूद नहीं है को अक्षम करके किया है मैं कैसे एक IDE में यह करने के लिए पता नहीं है; हालांकि एक जटिल निर्माण प्रक्रिया के माध्यम से निर्माण करना संभव है।

आप की आवश्यकता होगी:

  1. विधानसभा एक
  2. विधानसभा बी
  3. स्टब विधानसभा बी

जहां स्टब विधानसभा बी सार्वजनिक क्लासों और विधानसभा बी और उसी के सार्वजनिक तरीकों में शामिल है AssemblyInfo। * और एक ही सार्वजनिक कुंजी का संदर्भ देता है।

बिल्ड आदेश:

  1. संकलित स्टब विधानसभा बी
  2. कॉपी स्टब सभा के विधानसभा बी
  3. विधानसभा
  4. बिल्ड ए
  5. विधानसभा बिल्ड बी

सूचना उत्पादन निर्देशिका के लिए बी कि आपके पास विधि हस्ताक्षर में प्रकारों के प्रत्यक्ष पाश संदर्भ नहीं हो सकते हैं; हालांकि आप ऑब्जेक्ट के माध्यम से कास्टिंग करके प्रभावी लूप प्राप्त कर सकते हैं।

नोट:

ilasm सच पारस्परिक रूप से पुनरावर्ती विधानसभाओं संकलन किसी भी तरह के रूप में यह प्रकार है कि संकलन समय पर मौजूद नहीं है हल कर सकते हैं कर सकते हैं।

आगे:

aspnet_compiler एक ही परियोजना में विभिन्न भाषाओं मिश्रण करने में सक्षम हो (जो जानता है कि कैसे) लगता है।

+3

आप एक और अधिक जटिल निर्माण प्रक्रिया का उपयोग कर विधि हस्ताक्षर के प्रकारों में लूप प्राप्त कर सकते हैं: पहले सभी वर्गों को परिभाषित करें और संकलित करें, फिर विरासत पदानुक्रम (पिछले चरण से स्टब्स का उपयोग करके) सेट करें और सभी गैर-ओवरराइड विधियों को जोड़ें (लेकिन शरीर के बिना), और एक तिहाई पास में अंततः एक सामान्य संकलन (अब अंततः विधि निकायों सहित) करते हैं। यदि आप वास्तव में ऐसा करना चाहते हैं, तो #if आपका नया सबसे अच्छा दोस्त होगा। – Daniel

+0

वाह डैनियल मैंने कभी इसके बारे में सोचा नहीं। – Joshua

2

मैं इसे कैसे VB में काम करेगा पता नहीं है, लेकिन सैद्धांतिक रूप से यह उनमें से एक संकलन के लिए अन्य (पैदा अवैध कोड) की ओर इंगित करता प्लेसहोल्डर किसी तरह का उपयोग करते हैं, और उसके बाद का उपयोग करें कि संकलित करने के लिए करने के लिए संभव हो जाना चाहिए दूसरा, और फिर पहले recompile।

उदाहरण के लिए, गोलाकार निर्भरता संकल्प एक दूसरे की आवश्यकता वाले प्रोग्राम संकलित करते समय काम करता है।

--Though आमतौर पर कि सुविधाओं है कि अभी तक

+3

एफवाईआई, देशी सी और सी ++ में हम हेडर फाइलों के आधार पर इसे पूरा करते हैं। – Joshua

+0

@ जोशुआ, यह काम करता है अगर दोनों परस्पर निर्भर चीजें संकलित और एक ही समय में जुड़ी हुई हैं। "अभी तक मौजूद सुविधाओं को अक्षम करने" का उत्तर का वर्णन पैकेज प्रबंधक की सहायता से पैकेज स्तर पर चक्र तोड़ने के लिए अक्सर किया जाता है। – binki

+0

हम्म मेरा पैकेज मैनेजर चक्रीय निर्भरताओं को संभाल सकता है। – Joshua

6

भले ही mscorlib.dll और System.dll असेंबली पारस्परिक रूप से निर्भर हैं, मैं सलाह देता हूं कि 2 असेंबली परस्पर निर्भर न हों।

नेमस्पेस जैसे चित्रों के बीच निर्भरता चक्रों के बारे में, मैं dependency cycles का पता लगाने और इससे बचने के लिए एनडेंडेंड का उपयोग करने की सलाह दूंगा। लेख से

alt text

अंश (मैंने लिखा): Control component dependencies to gain clean architecture घटकों के बीच

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

इससे पता चलता है कि 500 ​​एलओसी (कोड ऑफ लाइन्स) के विकास और रखरखाव की संभावना 500 एलओसी के विकास और रखरखाव की तुलना में तीन या चार गुना अधिक होगी, जब तक कि इसे प्रत्येक 500 एलओसी के दो स्वतंत्र गांठों में विभाजित नहीं किया जा सके। इसलिए स्पेगेटी के साथ तुलना जो उलझन वाले कोड का वर्णन करती है जिसे बनाए रखा नहीं जा सकता है। आर्किटेक्चर को तर्कसंगत बनाने के लिए, किसी को यह सुनिश्चित करना चाहिए कि घटकों के बीच कोई निर्भरता चक्र न हो, लेकिन यह भी जांचें कि प्रत्येक घटक का आकार स्वीकार्य है (500 से 1000 LOC)।

+2

एक बहुत विचारशील और सूचनात्मक प्रतिक्रिया। मैं बस यह इंगित करना चाहता हूं कि, मैं मुख्य रूप से इस प्रश्न को सी # और वीबी.नेट के संयोजन में एक घटक लिखने में सक्षम होने के परिप्रेक्ष्य से पूछ रहा था। तो हालांकि मुझे "सुपर-घटक" से आपका क्या मतलब है, मुझे लगता है कि यह मेरे बाद के बाद से काफी मेल नहीं खाता है। मेरे लिए एक "सुपर-घटक" एकाधिक पारस्परिक रूप से निर्भर घटकों का संयोजन होगा; एक "मिश्रित घटक", जैसा कि मैं इसे कहूंगा, दूसरी तरफ, एक * एकल * घटक के पारस्परिक रूप से निर्भर * भागों * में अपघटन (भाषा द्वारा) होगा। क्या इसका कोई मतलब है? –

+0

आपको VB.NET या C# चुनना चाहिए, और दूसरी भाषा को भाषा चुनने के लिए माइग्रेट करें (उदाहरण के लिए .NET प्रतिबिंबक की मदद से, जो सी # को वीबी.नेट कोड या इसके विपरीत में परिवर्तित कर सकता है)। एक ही असेंबली को कोड करने के लिए 2 भाषाओं को बनाए रखने के अच्छे कारण नहीं हो सकते हैं। –

1

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

हालांकि मुझे उम्मीद नहीं है कि विज़ुअल स्टूडियो ने कभी भी इसका समर्थन किया है।


वहाँ भी चाल आप कर सकते हैं कि लिंकर बता एक से दूसरे विधानसभा से एक प्रकार के लिए एक अनुरोध को रीडायरेक्ट करने होंगे। माइक्रोसॉफ्ट इनका उपयोग करता है फिर वे .net ढांचे के भीतर प्रकारों को ले जाते हैं। यह केवल तभी मूल्य है यदि आप अपने सभी कॉलर्स को कोड को फिर से कंपाइल करने के लिए प्राप्त नहीं कर सकते हैं।

0

यदि आप सशर्त संकलन का उपयोग करते हैं तो दृश्य स्टूडियो में परिपत्र निर्भरता होना संभव है। अधिकांश समय सर्कुलर संदर्भ को शुरू करने के लिए सबसे अच्छा होगा, लेकिन यदि आपके पास रखने के लिए कोई अच्छा कारण है, तो this solution को इसे बनाने के लिए कामकाज के रूप में उपयोग किया जा सकता है।

संबंधित मुद्दे

 संबंधित मुद्दे