.NET COM Callable Wrapper आईआईडी कैसे उत्पन्न करता है?

Question

सीसीडब्ल्यू द्वारा बनाई गई जेनरेट की गई टीएलबी फ़ाइल को देखते हुए हालांकि ओएलई/कॉम ऑब्जेक्ट व्यूअर दिखाता है कि आईआईडी स्थिर रहता है जब तक कि मैं इंटरफ़ेस का डिज़ाइन बदलता हूं (जो सही व्यवहार है), मेरी चिंता यह है कि यदि मैं इस कोड को दूसरे पर संकलित करता हूं इंटरफ़ेस नहीं बदल रहा है और इसलिए मौजूदा COM क्लाइंट को तोड़ने के बावजूद मशीन पूरी तरह से अलग आईआईडी उत्पन्न की जाएगी।

1. COM कॉलबल रैपर द्वारा उत्पन्न COM इंटरफ़ेस आईडी कैसे हैं?
2. सीसीडब्ल्यू कैसे जानता है कि इंटरफ़ेस बदल गया है और एक नया आईआईडी उत्पन्न करने की आवश्यकता है?
3. क्या यह सिर्फ खुद को उत्पन्न करने और स्रोत फ़ाइल में घोषित करना सुरक्षित होगा?

Answer 1

एक प्रकार के लिए guid COM interop के लिए विशिष्ट नहीं है, सभी .NET प्रकारों में एक guid है। आप इसे Type.GUID प्रॉपर्टी से प्राप्त कर सकते हैं। सीएलआर में जो कोड उत्पन्न करता है वह एसएससीएलआई 20 वितरण से उपलब्ध है। आप clr/scr/vm/methodtable.cpp, MethodTable :: GetGuid() विधि में कोड को चेक करके एल्गोरिदम पर एक नज़र डालें।

सारांश एल्गोरिथ्म: प्रकार है

• अगर [Guid] विशेषता तो लौट कि
• यदि प्रकार है एक अंतरफलक प्रकार तो इंटरफ़ेस प्रकार परिभाषा के stringized संस्करण उत्पन्न करते हैं। यह interStutil.cpp में GetStringizedItfDef() द्वारा किया जाता है। यह पूरी तरह से योग्य प्रकार के नाम से शुरू होता है और प्रत्येक सदस्य परिभाषा का एक स्ट्रिंग संस्करण जोड़ता है।
• अन्य सभी प्रकार के लिए, कक्षा का एक स्ट्रिंग संस्करण उत्पन्न करें। यह पूरी तरह से योग्य प्रकार के नाम से शुरू होता है, कक्षा का नाम जोड़ता है और पूरी तरह से योग्य असेंबली नाम जोड़ता है।
• परिणामस्वरूप स्ट्रिंग को सहायक कार्य CorGuidFromNameW() द्वारा एक ग्रिड में धोया जाता है।

यह पर्याप्त जानकारी आपके सवालों के जवाब के लिए है:

कैसे COM इंटरफ़ेस आईडी COM प्रतिदेय आवरण द्वारा उत्पन्न कर रहे हैं?

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

सीसीडब्ल्यू कैसे जानता है कि इंटरफ़ेस बदल गया है और एक नया आईआईडी उत्पन्न करने की आवश्यकता है?

ऐसा नहीं है। यह पूरी तरह से विभिन्न इंटरफ़ेस परिभाषाओं के लिए अलग-अलग GUID का उत्पादन करने वाले एल्गोरिदम पर निर्भर करता है।

क्या यह केवल खुद को उत्पन्न करने और स्रोत फ़ाइल में घोषित करना सुरक्षित होगा?

वास्तव में नहीं। इस एल्गोरिदम के लिए कोई दस्तावेज विफलता मोड नहीं है। अपने स्वयं के [ग्रिड] विशेषता का उपयोग करने से आप उन बाधाओं को काफी हद तक बढ़ा सकते हैं जिन्हें आप बदलना भूल जाते हैं। यह एक शॉर्टकट है जिसे अक्सर लिया जाता है और डीएलएल नरक का प्राथमिक स्रोत होता है।गंदा प्रकार, जिस प्रकार क्लाइंट दुर्घटनाओं को हार्डवेयर अपवादों का निदान करने के लिए असंभव के साथ दुर्घटनाग्रस्त बनाता है। अभी भी कठिन-लेकिन-असंभव प्रकार के E_NOINTERFACE के विरोध में। ऑटो-जेनरेट किए गए ग्रिड पर भरोसा करके केवल दो नुकसान हैं जो मैं सोच सकता हूं: यह आपके देव मशीन पर रजिस्ट्री प्रदूषण का कारण बनता है जब आप उन्हें पुनर्निर्माण से पहले असेंबली को अपंजीकृत करना भूल जाते हैं। और जब आप COM त्रुटियों का निवारण कर रहे हैं तो यह आपको थोड़ा धीमा कर देता है क्योंकि आप आसानी से guids को नहीं जानते हैं। माना जाता है कि रजिस्ट्री प्रदूषण मेरे लिए पर्याप्त कारण है।