मेरी परियोजना (किसी प्रकार का प्रसंस्करण इंजन) 2 डीएलएस में विभाजित है: एक इंटरफ़ेस घोषणाओं और कार्यक्षमता के साथ एक। आमतौर पर प्रोजेक्ट का उपयोग बाहरी प्रौद्योगिकी के माध्यम से बाहरी डेल्फी प्रोजेक्ट द्वारा किया जाता है।केवल मेरे डीएलएल कोडेबेस से लोड करने योग्य कैसे करें?
आइए कहें कि मेरा प्रोग्राम फल फिसलता है। बाहरी डेल्फी प्रोग्राम फल ऑब्जेक्ट बनाता है और इसकी गुणों को भरता है: वजन (int), नाम (स्ट्रिंग) और प्रोग्रेसअपडेटर (प्रकार का IProgressUpdater जिसे इंटरफेस के साथ दूसरे डीएल में घोषित किया जाता है)। इस एक्सस्ट प्रोग्रामर निर्माता स्लाइसर के बाद, स्लाइसर बनाता है। एडफ्रूट (न्यूफ्रूट) और Slicer.Slice() कहते हैं।
कुछ खास नहीं है। वास्तविक जीवन में डेल्फी परियोजना आउटलुक एडिन है। लेकिन यहां समस्या है - कभी-कभी कुछ VSTO addins Outlook को "छाया प्रतिलिपि फ़ाइलें" मोड में काम करते हैं, इसलिए जब डेल्फी प्रोजेक्ट प्रारंभ होता है और स्लाइसर ऑब्जेक्ट बनाता है, तो हमारी सी # असेंबली अस्थायी फ़ोल्डर में रखी जाएगी और असेंबली इस स्थानीय पथ के साथ बनाई जाएगी। खैर ... यह अभी भी एक मुद्दा नहीं है। लेकिन समस्या तब होती है जब डेल्फी प्रोजेक्ट न्यूफ्रूट बनाता है और फिर मेरी स्लीकर असेंबली में प्रोग्रेसअपडेटर ऑब्जेक्ट पास करता है, मुझे बाहरी प्रोग्रेस अपडेटर नहीं मिल सकता है: "रिटर्न तर्क में एक अवैध प्रकार है", लेकिन फिर भी सरल प्रकार (वजन, नाम) के साथ फ़ील्ड प्राप्त कर सकते हैं।
यह तब होता है जब shadowCopyFiles मोड चालू होता है। तो मेरा अनुमान है - बाहरी प्रगति अपडेटर की असेंबली और स्लाइसर असेंबली अलग-अलग स्थानों पर रखी जाती है, इसलिए उन्हें पास नहीं किया जा सकता है। मेरा सवाल यह है कि कैसे मेरे डीएल को "छाया प्रतिलिपि" से बचने के लिए? या क्या कोई अलग समाधान है?
मैं COM प्रौद्योगिकी के साथ बहुत familiiar नहीं हूँ, लेकिन जीएसी से असेंबली नहीं लेनी चाहिए? की तरह [यहां] (http://edn.embarcadero.com/article/32754) – netaholic
हम्म, आप एक और एडिन के संदिग्ध प्रथाओं का शिकार हैं। यदि आपके पास टेलीफोन नंबर नहीं है तो आप इसके बारे में ज्यादा कुछ नहीं कर सकते हैं। लेकिन एक बात, जीएसी का प्रयोग करें। जब आप कॉमविज़िबल असेंबली लिखते हैं तो हमेशा एक अच्छा विचार। –
@ हंसपैसेंट समस्या यह है कि मेरी असेंबली पहले से ही जीएसी में पंजीकृत है। लेकिन एक मामले में विधानसभा। GetExecutingAssembly() स्थान; कोडबेस पथ दिखाता है (पथ जहां यह COM इंटरऑप के लिए regasm के साथ पंजीकृत था)। लेकिन दूसरे में (उस VSTO एड-इन के बाद) - सिस्टम ड्राइव पर कुछ अस्थायी पथ। मुझे लगता है कि अगर मुझे कोडबेज पथ से केवल मेरी असेंबली लोड करने के लिए मजबूर किया जा सकता है तो मुझे ऐसी समस्या नहीं होगी। – Shelest