क्या GUID द्वारा बजाए किसी प्रबंधित प्रोजेक्ट में एक COM DLL को संदर्भित करना संभव है?

Question

मेरे पास एक प्रबंधित (asp.net, वास्तव में) प्रोजेक्ट है जो COM DLL का संदर्भ देता है।

<COMReference Include="thenameinquestion"> 
    <Guid>{someguidhere}</Guid> 
    <VersionMajor>1</VersionMajor> 
    <VersionMinor>0</VersionMinor> 
    <Lcid>0</Lcid> 
    <WrapperTool>tlbimp</WrapperTool> 
</COMReference> 

यह काम करता है, लेकिन यह दुर्भाग्यपूर्ण परिणाम है कि DLL निर्माण मशीन, जिसका अर्थ है पर पंजीकृत होना आवश्यक है (अन्य बातों के अलावा) है यह असुविधाजनक है: अभी, .csproj में संदर्भ इस तरह दिखता है प्रोजेक्ट के कई संस्करणों का निर्माण करने के लिए जो एक ही निर्माण मशीन पर डीएलएल के विभिन्न संस्करणों का उपयोग करते हैं।

एमएसडीएन ResolveComReference कार्य दिखाता है जो ऐसा लगता है कि यह सही काम करता है, लेकिन मेरा google-search-fu इसके उपयोग के वास्तविक उदाहरण के साथ पर्याप्त नहीं रहा है। क्या मैं ऐसा करना चाहता हूं? क्या मैं सही रास्ते पर हूं?

Answer 1

यह आलेख दिखाता है कि COM घटकों के पंजीकरण-मुक्त सक्रियण कैसे करें। शायद यह मदद करेगा: http://msdn.microsoft.com/en-us/library/ms973913.aspx

Answer 2

John Fisher के रूप में पहले से ही आप Registration-Free COM Interop देख रहे हैं। इसके बारे में पहले से ही बहुत सारे प्रश्न हैं, 'टैग पर हाथ' regfreecom और निकट से संबंधित टैग sxs भी देखें।

आप आसानी से देखेंगे, तथापि, कि यह एक मुश्किल क्षेत्र हो सकता है, विशेष रूप से:

• वहाँ, Windows XP पर इस को प्रभावित करने वाले एक confirmed बग हो जानकारी के लिए here देखने के लिए प्रकट होता है। एक हॉटफिक्स पहले से ही उपलब्ध है, जो तब तक पर्याप्त हो सकता है जब तक आप केवल एक नियंत्रित वातावरण को लक्षित कर रहे हों, उदा। आपकी बिल्ड मशीन
• चूंकि आप एएसपी.नेट को लक्षित कर रहे हैं, आपको अवगत होना चाहिए कि इसके विपरीत डेस्कटॉप एप्लिकेशन का तात्पर्य यह है कि आप होस्टिंग प्रक्रिया के नियंत्रण में नहीं हैं, जो तैनाती प्लेटफ़ॉर्म के आधार पर भिन्न हो सकते हैं। इसका मतलब यह है कि मेजबान के भीतर अपने COM घटक के रनटाइम बाध्यकारी और सक्रियण को नियंत्रित करने के लिए आवश्यक एप्लिकेशन मैनिफेस्ट को आपूर्ति करना आसान नहीं होगा (संभावित विकल्प के लिए अगला बिंदु देखें)।
• एएसपी.नेट 2.0 अप्रबंधित घटकों के लिए साइड कार्यक्षमता को छोड़कर चीजों को और जटिल बना देता है। मुझे इसके लिए एक आधिकारिक स्रोत नहीं मिला है लेकिन Isolating ASP .Net 2.0 Applications के लेखक को पता है; वह कम से कम एक वर्कअराउंड पेश कर रहा है, जो जटिल और संभावित रूप से नाजुक दिखता है।

संक्षेप में यह कहना है कि 'पंजीकरण-मुक्त COM इंटरऑप' बहुत उपयोगी हो सकता है और कई परिदृश्यों को बहुत कम कर सकता है। फिर भी यह आपके विशेष परिदृश्य और पर्यावरण (होस्टेड एएसपी.नेट) के लिए चीजों को आसान या यहां तक ​​कि संभव नहीं हो सकता है।

शुभकामनाएं, कृपया हमें बताएं कि आप सफल हुए हैं या नहीं!

Answer 3

ऐसा लगता है कि यह संभव नहीं है - विजुअल स्टूडियो केवल संदर्भ में उल्लिखित GUID को देखेगा, यह वहां संकेतित पथ की परवाह नहीं करता है।

हमें हमारे दैनिक निर्माण सर्वर के साथ एक ही समस्या थी - COM क्लाइंट संकलित नहीं होगा जब तक कि COM सर्वर पंजीकृत न हो। हमने अभी निर्माण अनुक्रम में पंजीकरण/अनियंत्रण जोड़ा - यह घटक (regsv32) घटक को पंजीकृत करता है, फिर वीएस कमांड लाइन से चलाया जाता है और तुरंत वीएस पूरा होने पर यह घटक (regsvr32 -u) को अनियंत्रित करता है। आसानी से दौडें।

Answer 4

जब आप एक COM DLL संदर्भित करते हैं, तो विजुअल स्टूडियो स्वचालित रूप से इसके लिए एक इंटरऑप असेंबली उत्पन्न करता है।मुझे लगता है कि इस प्रक्रिया का मैन्युअल नियंत्रण लेना COM और .NET बिल्ड को रद्द करने का एक शानदार तरीका है।

1. tlbimp.exe का उपयोग कर COM DLL के लिए अपनी स्वयं की इंटरऑप असेंबली बनाएं। कमांड लाइन पैरामीटर के लिए MSDN देखें।
2. COM DLL के के बजाय .NET प्रोजेक्ट में अपनी इंटरऑप असेंबली का संदर्भ लें।

एक बार ऐसा करने के बाद, जब आप .NET समाधान बनाते हैं तो आपको मशीन पर COM DLL पंजीकृत नहीं होना चाहिए, केवल आपकी इंटरऑप असेंबली आवश्यक है।

इंटरऑप असेंबली एक फ़ोल्डर में हमेशा के लिए अपरिवर्तित फ़ोल्डर में बैठ सकता है (ए) COM DLL बाइनरी संगतता को तोड़ता है, या (बी) एक COM इंटरफ़ेस परिवर्तन यह होता है कि .NET कोड वास्तव में उपयोग करता है।

यदि आपके पास COM DLL के विभिन्न संस्करण हैं जो सभी बाइनरी संगत हैं, तो इंटरफ़ेस असेंबली को प्रारंभिक संस्करण के साथ संकलित करें जिसमें .NET कोड की आवश्यकता होती है। इसके बाद आपको विभिन्न संस्करणों के लिए इंटरऑप असेंबली अपडेट नहीं करना पड़ेगा।

इसके अतिरिक्त, आपको अपने इंस्टॉलर में COM DLL शामिल करने की आवश्यकता नहीं है यदि आप यह मानने की स्थिति में हैं कि COM DLL पहले से ही लक्ष्य मशीन पर स्थापित हो जाएगा।