نطاق المجمع القابل للاستدعاء في وقت التشغيل (RCW) - مجال العملية أم التطبيق؟

Question

ما هو نطاق Runtime Callable Wrapper (RCW) عند الإشارة إلى كائنات COM غير المُدارة؟وفقا للمستندات:

يقوم وقت التشغيل بإنشاء RCW واحد تمامًا لكل كائن COM ، بغض النظر عن عدد المراجع الموجودة على هذا الكائن.

إذا اضطررت إلى "التخمين" - فيجب أن يعني هذا التفسير "واحدًا لكل عملية"، ولكن هل هذا صحيح حقًا؟أي وثائق إضافية سيكون موضع ترحيب كبير.

يعمل التطبيق الخاص بي في مجال التطبيق الخاص به (وهو برنامج Outlook الإضافي)، وأود أن أعرف ماذا يحدث إذا استخدمت Marshal.ReleaseComObject(x) في حلقة حتى يصل عددها إلى 0 (كما هو موصى به).هل سيتم تحرير مراجع من الوظائف الإضافية الأخرى (التي تعمل في مجال تطبيق آخر في نفس عملية Outlook)؟

يحرر:مثالي - الآن أصبح الارتباك أكبر.بناءً على الإجابتين (من Lette وIlya) لدينا إجابتان مختلفتان.الرسمي وثيقة MSDN يقول لكل عملية (للإصدار.2.0+)، ولكن هذه الجملة مفقودة الاصدار.1.1 من الوثيقة.

وفي الوقت نفسه، في مقالة Mason Bendixen، تقول إنها لكل مجال تطبيق.

وبما أن مقالته قديمة (أبريل 2007)، فقد أرسلت له بريدًا إلكترونيًا أطلب منه التوضيح، ولكن إذا أراد شخص آخر إضافة شيء ما، فيرجى القيام بذلك.

شكرًا

Answer 1

<اقتباس فقرة>   

في إدارتها، لدينا في مجال التطبيق   مخبأ   رسم IUnknowns الكنسي العودة إلى   RCWs. عندما يكون IUnknown يدخل   النظام (من خلال مكالمة المشير،   من خلال التنشيط، بمثابة عودة   المعلمة من استدعاء أسلوب، وما إلى ذلك)،   علينا التحقق من ذاكرة التخزين المؤقت إلى معرفة ما إذا كان RCW   موجود بالفعل لكائن COM. إذا   يوجد رسم الخرائط، في إشارة إلى   يتم إرجاع RCW القائمة. خلاف ذلك   RCW جديد يتم إنشاؤه وتعيين مخبأ   يضاف.

ميسون مدونة

Answer 2

مقالة مدونة Mason Bendixen التي استشهد بها إيليا صحيحة:يتم تحديد نطاق RCW إلى AppDomain، وليس إلى العملية.لا أستطيع إلا أن أخمن أن غلاف قابل للاستدعاء في وقت التشغيل (MSDN 2.0) كان المقال يتحدث "عرضا".هذه المقالة ليست بالضرورة غير صحيحة بالمعنى العام، لأنه من المعتاد التنفيذ باستخدام AppDomain واحد فقط، ولكن هذه الجملة ليست دقيقة من الناحية الفنية.

أما بالنسبة لسؤالك المحدد:

"أود أن أعرف ما يحدث إذا استخدمت Marshal.ReleAsecomObject (X) في حلقة حتى يصل عددها إلى 0 (كما هو موصى به).هل سيصدر مراجع من الإضافات الأخرى (تعمل في مجال التطبيق الآخر في نفس عملية Outlook) ؟؟ "

تعتمد الإجابة على هذا السؤال على كيفية إعداد الوظيفة الإضافية الخاصة بك.بشكل عام، إذا لم تتخذ الاحتياطات اللازمة، فالإجابة هي نعم، فسيؤثر ذلك على المراجع في الوظائف الإضافية الأخرى التي تعمل من داخل نفس AppDomain.ولكن بما أنك ذكرت أنك تعمل من AppDomain منفصل، فلا، لن يحدث ذلك.

هناك إصدار معالج COM Shim 2.3.1 التي يمكنك استخدامها لعزل الوظيفة الإضافية الخاصة بك.يمكن العثور على وثائق معالج COM Shim هنا: عزل ملحقات Microsoft Office باستخدام الإصدار 2.3.1 من معالج Shim COM.

يستخدم معالج COM Shim الانعكاس لإنشاء أداة تحميل أمامية COM مخصصة تقوم بتحميل تجميع الوظيفة الإضافية داخل AppDomain منفصل.وهذا يخلق الأمان من ناحيتين:

(1) باستخدام نقطة إدخال COM منفصلة ومخصصة، يتم تعريف الوظيفة الإضافية بشكل صحيح بشكل منفصل بواسطة Microsoft Office عن كافة الوظائف الإضافية الأخرى.بخلاف ذلك، بشكل افتراضي، تشترك كافة الوظائف الإضافية في نفس أداة تحميل mscoree.dll الافتراضية.المشكلة في مشاركة نفس المُحمل هي أنه في حالة تعطل أي وظيفة إضافية، فسيتم تحديد mscoree.dll بواسطة Microsoft Office كمصدر للمشكلة ولن يتم تحميله تلقائيًا في المرة التالية.يمكنك تشغيلها مرة أخرى يدويًا، ولكن لن يتم تحميل الوظيفة الإضافية الخاصة بك تلقائيًا في المرة القادمة بسبب حدوث مشكلة في الوظيفة الإضافية الخاصة بشخص آخر!

(2) عن طريق تحميل التجميع الخاص بك داخل AppDomain منفصل، يتم عزل الأغلفة القابلة للاستدعاء في وقت التشغيل (RCWs) عن الوظائف الإضافية الأخرى التي تم تحميلها في نفس العملية.في هذه الحالة، إذا اتصلت بـ Marshal.ReleaseComObject(object) أو Marshal.FinalReleaseComObject(object)، فلن تؤثر على الوظائف الإضافية لأي شخص آخر.والأهم من ذلك، إذا قامت أي من هذه الوظائف الإضافية الأخرى بإجراء مثل هذه المكالمات، فستكون الوظيفة الإضافية الخاصة بك محمية من التلف.:-)

الجانب السلبي لاستخدام COM Shim Wizard هو أنه من خلال التشغيل خارج نطاق AppDomain منفصل، هناك حمل إضافي للتنظيم.لا أعتقد أن هذا يجب أن يكون ملحوظًا بالنسبة لوظيفة Microsoft Outlook الإضافية.ومع ذلك، يمكن أن يكون عاملاً بالنسبة لبعض الإجراءات المكثفة التي تحتوي على الكثير من الاستدعاءات لنموذج الكائن، كما هو الحال أحيانًا بالنسبة لوظيفة Microsoft Excel الإضافية.

لقد ذكرت أنك تقوم بالفعل بتشغيل الوظيفة الإضافية الخاصة بك من AppDomain منفصل.إذا كان هذا صحيحًا، فأنت معزول بالفعل عن استدعاءات Marshal.ReleaseComObject(object) وMarshal.FinalReleaseComObject(object) فيما يتعلق بمجالات AppDomains الأخرى.(أنا فضولي لمعرفة كيف تفعل هذا، بالمناسبة...هل تقوم بشكل صريح بإنشاء AppDomain الخاص بك؟قالب الوظيفة الإضافية الافتراضي في Visual Studio يفعل ذلك لا تشغيله في AppDomain منفصل ويتم تحميله باستخدام mscoree.dll.)

إذا كنت تقوم بإنشاء AppDomain الخاص بك، فسيتم عزل التعليمات البرمجية الخاصة بك، ولكن قد لا تكون هويتها منفصلة عن الوظائف الإضافية الأخرى، حيث ستظل الوظيفة الإضافية الخاصة بك تشارك أداة تحميل mscoree.dll الافتراضية، إلا إذا استخدمت بعض الوسائل الأخرى لمعالجة هذا.

آمل أن يساعد هذا...

Answer 3

وفقًا لنفس المستندات:

يحتفظ وقت التشغيل بـ RCW واحد لكل عملية لكل كائن.

أعتقد أنه يمكننا أن نفترض ذلك بأمان هدف = مثال, ، لذلك إذا كانت الوظائف الإضافية/AppDomains لا تحتوي على مراجع لنفس المثيل، فسيتم الاتصال بـ ReleaseComObject لن يصدر مراجع للمثيلات التي تم إنشاؤها في مكان آخر.

يحرر:قد تكون صياغة المستندات خاطئة، كما ذكر في مكان آخر.إذا كان الأمر كذلك، فنظرًا لأن الوظيفة الإضافية الخاصة بك تعمل في AppDomain منفصل، فأنت محظوظ.حتى لو كانت الوظائف الإضافية المختلفة تشير إلى نفس المثيل (على سبيل المثال.كائن رسالة في Outlook)، ReleaseComObject لن يتسبب الاتصال في AppDomain الخاص بك في فقدان RCWs في AppDomains الأخرى للإشارة إلى هذا المثيل.