2013-02-21 54 views
10

अब, मुझे पता है कि यदि पुस्तकालय .NET में है, तो COM के माध्यम से इसे एक्सेस करने के लिए थोड़ा सा व्यर्थ है, हालांकि, मैं थोड़ा परेशान हूं क्योंकि अगर मैं किसी को पुस्तकालय लिखने और COM के माध्यम से इसका खुलासा करने के लिए कहता हूं , उस व्यक्ति को किसी भी भाषा के साथ ऐसा करने के लिए स्वतंत्र होना चाहिए।.NET COM लाइब्रेरी का उपयोग .NET में COM के माध्यम से क्यों नहीं किया जा सकता है?

इससे कोई फर्क नहीं पड़ता कि COM पुस्तकालय किस भाषा में लिखा गया है, तो यह क्यों मायने रखता है?

C:\dev>tlbimp test.tlb 
Microsoft (R) .NET Framework Type Library to Assembly Converter 4.0.30319.1 
Copyright (C) Microsoft Corporation. All rights reserved. 

TlbImp : error TI1029 : Type library 'test' was exported from 
a CLR assembly and cannot be re-imported as a CLR assembly. 

साथ ही, अपने परीक्षण COM पुस्तकालय IUnknown का उपयोग करता है, केवल जल्दी ही सीमित कॉम इंटरॉप समर्थन:

संदर्भ के लिए, यह है कि क्या होता है जब आप एक .NET पुस्तकालय से उत्पन्न एक .tlb फ़ाइल पर tlbimp का उपयोग करें ।

+0

pst: tlbimp.exe मुझे प्रकारों को आयात करने से इंकार कर देता है। – Arafangion

+0

pst: आप .NET में COM के माध्यम से .NET COM लाइब्रेरी का उपयोग कैसे करेंगे? – Arafangion

+0

tlbimp.exe स्वचालित रूप से निकालने/बाइंडिंग बनाने के लिए एक उपकरण है। इसकी आवश्यकता नहीं है और पूरी प्रक्रिया हाथ से की जा सकती है, जैसे .NET में खपत किसी भी अन्य COM इंटरफ़ेस के लिए। –

उत्तर

11

tlbimp केवल समस्या की शुरुआत है।

प्रत्येक COM-visible .NET ऑब्जेक्ट IManagedObject लागू करता है। प्रत्येक बार जब आप एक COM इंटरफ़ेस के माध्यम से किसी ऑब्जेक्ट को कॉल करने का प्रयास करते हैं, तो .NET IManagedObject के लिए क्वेरी क्वेरी इंटरफेस करता है, और यदि यह ऑब्जेक्ट को सफल बनाता है तो उसे अनचाहे और सीधे एक्सेस किया जाता है। इस तरह इंटरऑप कॉल को खत्म करना एक प्रदर्शन अनुकूलन माना जाता है।

यह COM-based इंटरऑप परिदृश्यों में एक गंभीर समस्या है जहां कई घटक .NET भाषाओं में लागू किए जा सकते हैं। यदि प्रत्येक .NET घटक COM इंटरफ़ेस के अपने स्वयं के tlbimp- जेनरेट किए गए संस्करण को लागू करता है, तो वे उस इंटरफ़ेस का उपयोग करके एक दूसरे के साथ संवाद करने में असमर्थ होंगे। हालांकि इंटरफ़ेस की प्रत्येक tlbimp'ed प्रतिलिपि में एक ही COM GUID है, .NET उन्हें अलग इंटरफेस मानता है। इस समस्या का "सही" समाधान प्राथमिक इंटरऑप असेंबली में COM इंटरफ़ेस को परिभाषित करना है, और प्रत्येक .NET- कार्यान्वित घटक इंटरफ़ेस की एक ही प्रतिलिपि का उपयोग करता है, लेकिन यदि घटक डेवलपर्स के बीच कोई समन्वय नहीं होता है जो होने की संभावना नहीं है।

यह समस्या एक बार माइक्रोसॉफ्ट डेवलपर द्वारा http://blogs.msdn.com/b/jmstall/archive/2009/07/09/icustomqueryinterface-and-clr-v4.aspx पर .NET 4 के समाधान के साथ हाइलाइट की गई थी, लेकिन यह प्री-रिलीज संस्करण पर आधारित थी और अंतिम में काम नहीं करती थी। मुझे माइक्रोसॉफ्ट द्वारा कहीं भी स्वीकार किए जाने के बारे में पता नहीं है।

एक समाधान .NET-to-.NET परिदृश्य में इंटरफ़ेस को पूर्ववत करना है और इसके बजाय प्रतिबिंब का उपयोग करना है। यह कई मामलों में काम कर सकता है लेकिन निश्चित रूप से बहुत ही सक्षम नहीं है। संभावित रूप से सबसे अच्छा समाधान आपके प्रबंधित घटकों को एकत्रित करने के लिए अप्रबंधित कोड का उपयोग करना और IManagedObject के लिए QueryInterface के प्रयासों को अस्वीकार करना है। यह उपर्युक्त ब्लॉग एंट्री में वर्णित जैसा है, लेकिन .NET सुविधाओं पर भरोसा नहीं करता है जो अब उस ब्लॉग में वर्णित कार्य नहीं करता है।

.NET इंटरऑप व्यवहार, आईएमओ, बहुत भयानक है, और स्पष्ट रूप से COM नियमों का उल्लंघन करता है (समान IID == समान इंटरफ़ेस, और इस बात की परवाह नहीं करनी चाहिए कि ऑब्जेक्ट किस भाषा में लागू किया गया है)। परंतु ।नेट ने शुरुआत से इस तरह से व्यवहार किया है और इस व्यवहार से लिखे गए डेवलपर्स से प्रतिक्रिया की कोई भी संख्या ने .NET टीम पर किसी के दिमाग को बदल दिया है।

+0

बह, वह बेकार है। क्या आप संदर्भ प्रदान कर सकते हैं? – Arafangion

+0

भाग्यशाली ऑल-राउंड। क्या आप उपरोक्त उत्तर में उन संदर्भों को डाल सकते हैं, तो आपको बक्षीस मिलेगा। – Arafangion

+0

सब कुछ एक साथ मिला दिया। क्षमा करें, मैंने इतना उपयोग नहीं किया है और मुझे पोस्टिंग के बजाय संपादन करने के लिए अभी भी उपयोग नहीं किया जाता है। –

4

Tlbimp टाइप लाइब्रेरी से देख सकता है जिसे इसे .NET असेंबली से बनाया गया था। यह सिर्फ उस चीज पर झुकता है जो आप करने की कोशिश कर रहे हैं। जो समझ में नहीं आता है, अगर आप .NET असेंबली का उपयोग करना चाहते हैं तो बस इसके लिए एक संदर्भ जोड़ें।

आप देर से बाध्य COM का उपयोग करके मशीन को बेवकूफ़ बना सकते हैं, गतिशील कीवर्ड में सी # में आसानी से किया जा सकता है। वह अभी भी सीएलआर को मूर्ख नहीं बनाता है, यह देख सकता है कि यह एक प्रबंधित असेंबली के साथ बातचीत करता है और वास्तव में COM-Callable wrapper नहीं बनायेगा। आप आमतौर पर अपने COM सर्वर का परीक्षण करने के लिए एक परीक्षण प्रोग्राम लिखने के लिए ऐसा करते हैं। निहितार्थ यह है कि आपका परीक्षण वास्तव में आपके COM सर्वर का अभ्यास करने के तरीके का परीक्षण नहीं करता है। वेरिएंट को ऑब्जेक्ट्स और बैक में कनवर्ट करने जैसी बहुत ही बुनियादी चीजें बिल्कुल परीक्षण नहीं की जाएंगी। और जब आप उत्पादन में असेंबली का उपयोग करते हैं तो आपको बहुत अप्रिय आश्चर्य भी मिल सकता है।

+0

लेकिन लेट-बाउंड COM केवल आईडीस्पैच के साथ काम करता है, IU अज्ञात को प्रारंभिक COM की आवश्यकता होती है; दरअसल, यह सिस्टम परीक्षण के लिए है कि मैं COM इंटरफेस का उपयोग करना चाहता हूं। – Arafangion

+0

ठीक है, आपको मुफ्त में आईडीस्पैच मिलता है इसलिए इसे टालने में थोड़ा सा बिंदु है। लेकिन स्पष्ट रूप से परीक्षण के बारे में मेरी टिप्पणी यहां दृढ़ता से लागू होती है। –

+0

क्लाइंट एप्लिकेशन IU अज्ञात का उपयोग करेगा, इसलिए IDISpatch से बचने का अर्थ है कि मैं अपने परीक्षणों को IU अज्ञात इंटरफ़ेस का उपयोग करने के लिए मजबूर करता हूं। .NET हैंडल प्रबंधित COM पुस्तकालयों को कैसे प्रबंधित करता है, इस बारे में अच्छी जानकारी के लिए – Arafangion