रनटाइम कॉल करने योग्य रैपर (आरसीडब्लू) स्कोप - प्रक्रिया या एप्लिकेशन डोमेन?

Question

अप्रबंधित COM ऑब्जेक्ट्स का संदर्भ देते समय, रनटाइम कॉलबल रैपर (आरसीडब्ल्यू) का दायरा क्या है? डॉक्स के अनुसार:

क्रम प्रत्येक COM ऑब्जेक्ट के लिए ठीक एक RCW , संदर्भ उस वस्तु पर मौजूद संख्या की परवाह किए बिना बनाता है।

अगर मुझे "अनुमान लगाना" था - इस स्पष्टीकरण का मतलब "प्रति प्रक्रिया एक" होना चाहिए, लेकिन क्या यह वास्तव में है? कोई अतिरिक्त दस्तावेज बहुत स्वागत किया जाएगा।

मेरा एप्लिकेशन अपने स्वयं के एप्लिकेशन डोमेन (यह आउटलुक एडिन) में चलता है, और मैं जानना चाहता हूं कि अगर मैं मार्शल का उपयोग करता हूं तो मैं क्या करता हूं जब तक कि इसकी गणना 0 तक पहुंच जाती है (अनुशंसित)। क्या यह अन्य एडिन से संदर्भ जारी करेगा (उसी Outlook प्रक्रिया में अन्य एप्लिकेशन डोमेन में चल रहा है)?

संपादित करें: बिल्कुल सही - अब भ्रम भी बड़ा है। 2 उत्तरों (लेटे और इल्या से) के आधार पर हमारे पास 2 अलग-अलग उत्तर हैं। आधिकारिक MSDN doc प्रति प्रक्रिया (वर्जन 2.0+ के लिए) कहता है, लेकिन ver. 1.1 of the doc के लिए यह वाक्य गुम है।

उसी समय, मेसन बेंडिक्सन के लेख में, यह कहता है कि यह प्रति एपडोमेन है।

जैसा कि उसका लेख पुराना है (अप्रैल 2007), मैंने उसे स्पष्टीकरण मांगने के लिए एक ईमेल भेजा है, लेकिन अगर किसी और को कुछ जोड़ना है, तो कृपया करें।

धन्यवाद

Answer 1

कामयाब में, हम एप्लिकेशन डोमेन कैश वापस RCWs को मानचित्रण विहित IUnknowns प्रति एक है। एक IUnknown (एक मार्शल कॉल, सक्रियण के माध्यम से, एक विधि कॉल से एक वापसी पैरामीटर के रूप में, आदि के माध्यम से) प्रणाली प्रवेश करती है, हम अगर एक RCW पहले से ही COM वस्तु के लिए मौजूद है कैश की जाँच करें। यदि मैपिंग मौजूद है, तो मौजूदा आरसीडब्लू का संदर्भ वापस कर दिया गया है। अन्यथा नया आरसीडब्ल्यू बनाया गया है और कैश मैपिंग जोड़ा गया है।

Mason's Blog

Answer 2

ही डॉक्स के अनुसार:

क्रम प्रत्येक वस्तु के लिए प्रक्रिया प्रति एक भी RCW बनाए रखता है।

मुझे लगता है कि हम सुरक्षित रूप से मान सकते हैं कि वस्तु = उदाहरण, इसलिए यदि addins/AppDomains एक ही उदाहरण के लिए संदर्भ नहीं रखता है, ReleaseComObject करने के लिए कॉल को कहीं और बनाया उदाहरणों के लिए संदर्भ जारी नहीं करेगा ।

संपादित करें: दस्तावेज़ों का शब्द गलत हो सकता है, as stated elsewhere। यदि ऐसा है, चूंकि आपका ऐड-इन एक अलग ऐपडोमेन में चल रहा है, तो आप भाग्य में हैं। भले ही अलग-अलग ऐड-इन्स एक ही उदाहरण (उदाहरण के लिए Outlook में एक संदेश ऑब्जेक्ट) का संदर्भ लें, ReleaseComObject आपके ऐपडोमेन में कॉल किया गया है, अन्य ऐपडोमेन्स में आरसीडब्ल्यू को उस उदाहरण के संदर्भ को खोने का कारण नहीं होगा।

Answer 3

मेसन Bendixen ब्लॉग लेख कि इल्या का हवाला देते से सही है: RCW, AppDomain के दायरे वाला प्रक्रिया के लिए नहीं। मैं केवल अनुमान लगा सकता हूं कि Runtime Callable Wrapper (MSDN 2.0) आलेख "आकस्मिक" बोल रहा था। यह आलेख सामान्य अर्थ में जरूरी नहीं है, क्योंकि यह केवल एक ही ऐपडोमेन का उपयोग करके निष्पादित करना सामान्य है, लेकिन यह वाक्य तकनीकी रूप से सटीक नहीं है।

अपने विशिष्ट प्रश्न के रूप में:।

"मुझे पता है कि अगर मैं जब तक यह गिनती है 0 ( रूप में सिफारिश की) तक पहुँच जाता है एक पाश में Marshal.ReleaseComObject (x) का उपयोग क्या होता है चाहते हैं विल यह अन्य एडिन से संदर्भ (उसी एप्लिकेशन प्रक्रिया में अन्य एप्लिकेशन डोमेन में चल रहा है) ?? "

इसका उत्तर इस बात पर निर्भर करता है कि आपने अपना ऐड-इन कैसे सेट अप किया है। आम तौर पर, यदि आप सावधानी बरतते हैं, तो उत्तर हाँ है, यह उसी ऐडडोमेन के भीतर से चल रहे अन्य ऐड-इन्स में संदर्भों को प्रभावित करेगा। लेकिन चूंकि आप बताते हैं कि आप एक अलग ऐपडोमेन से चल रहे हैं, तो नहीं, ऐसा नहीं होगा।

एक COM Shim Wizard Version 2.3.1 है जिसका उपयोग आप अपने ऐड-इन को अलग करने के लिए कर सकते हैं। COM शिम विज़ार्ड के लिए प्रलेखन यहां पाया जा सकता है: Isolating Microsoft Office Extensions with the COM Shim Wizard Version 2.3.1।

COM शिम विज़ार्ड एक अनुकूलित COM फ्रंट-एंड लोडर बनाने के लिए प्रतिबिंब का उपयोग करता है जो आपकी ऐड-इन असेंबली को एक अलग ऐपडोमेन में लोड करता है। यह दो मामलों में सुरक्षा बनाता है:

(1) एक अलग, अनुकूलित कॉम प्रवेश बिंदु का उपयोग करके, अपने ऐड-इन को सही ढंग से अलग माइक्रोसॉफ्ट ऑफिस से अन्य सभी ऐड-इन्स से पहचाना जाता है। अन्यथा, डिफ़ॉल्ट रूप से, सभी ऐड-इन्स एक ही डिफ़ॉल्ट mscoree.dll लोडर साझा करते हैं। एक ही लोडर साझा करने में समस्या यह है कि यदि किसी ऐड-इन में कोई क्रैश होता है, तो mscoree.dll को Microsoft Office द्वारा समस्या के स्रोत के रूप में पहचाना जाएगा और अगली बार इसे स्वचालित रूप से लोड नहीं करेगा। आप इसे मैन्युअल रूप से फिर से चालू कर सकते हैं, लेकिन अगली बार किसी अन्य के ऐड-इन में किसी समस्या के कारण आपका ऐड-इन स्वचालित रूप से लोड नहीं होगा!

(2) अपनी असेंबली को एक अलग ऐपडोमेन के भीतर लोड करके, रनटाइम कॉल करने योग्य रैपर (आरसीडब्ल्यू) अन्य ऐड-इन्स से अलग होते हैं जो एक ही प्रक्रिया में लोड होते हैं। इस मामले में, यदि आप मार्शल को कॉल करते हैं। ReleaseComObject (ऑब्जेक्ट) या मार्शल। FinalReleaseComObject (ऑब्जेक्ट) तो आप किसी और के ऐड-इन्स को प्रभावित नहीं करेंगे। सबसे महत्वपूर्ण बात यह है कि, यदि उनमें से कोई अन्य ऐड-इन्स ऐसी कॉल करता है, तो आपका ऐड-इन दूषित होने से सुरक्षित होगा। :-)

कॉम शिम जादूगर है कि वहाँ एक अलग AppDomain से बाहर काम करते हुए अतिरिक्त मार्शलिंग भूमि के ऊपर है का उपयोग करने के नकारात्मक पक्ष यह है। मुझे विश्वास नहीं है कि यह माइक्रोसॉफ्ट आउटलुक ऐड-इन के लिए ध्यान देने योग्य होना चाहिए। हालांकि, यह एक कारक हो सकता है, हालांकि, कुछ गहन दिनचर्याओं के लिए जिनके पास ऑब्जेक्ट मॉडल पर बहुत सी कॉल हैं, जैसे कभी-कभी माइक्रोसॉफ़्ट एक्सेल ऐड-इन के मामले भी हो सकते हैं।

आपने कहा है कि आप पहले से ही अपने ऐड-इन को एक अलग ऐपडोमेन से चला रहे हैं। यदि यह सत्य है, तो आप पहले से ही मार्शल से अलग हैं। ReleaseComObject (ऑब्जेक्ट) और मार्शल। FinalReleaseComObject (ऑब्जेक्ट) अन्य AppDomains के संबंध में कॉल करता है। (मैं तुम ऐसा कैसे कर रहे हैं, जिस तरह से जानने के लिए उत्सुक हूँ ... आप स्पष्ट रूप से अपने खुद के AppDomain बनाने हैं? डिफ़ॉल्ट ऐड-इन टेम्पलेट दृश्य स्टूडियो में mscoree.dll का उपयोग कर अलग AppDomain और भार में नहीं रन करता है ।)

यदि आप अपना स्वयं का ऐपडोमेन बना रहे हैं, तो आपका कोड अलग है, लेकिन इसकी पहचान अन्य ऐड-इन्स से अलग नहीं हो सकती है, हालांकि, आपका ऐड-इन अभी भी डिफ़ॉल्ट mscoree.dll लोडर साझा करेगा, आपने इसका समाधान करने के लिए कुछ अन्य साधनों का उपयोग किया।

मुझे आशा है कि इस मदद करता है ...