C ++ COM C # مختلط الوضع Interoperation

Question

أحاول فهم خياراتي لاستدعاء تطبيق مكتبة C # من C ++ غير المدارة.

وحدة المستوى العلوي هي DLL غير المدارة C ++ COM / ATL DLL. أرغب في دمج وظائف C # DLL المدارة الحالية. لدي، ويمكن إعادة ترجمة المصدر لكل من المكتبات.

أنا أفهم من قراءة مقالات مثل هذا لمحة عامة على MSDN و هذا حتى السؤال أنه قد يكون من الممكن إنشاء DLL "مختلط" يتيح رمز C ++ الأصلي للاتصال بمكتبة C #.

لدي سؤالان حول هذا النهج:

1. كيف أذهب حول تحديد هذا؟ هل يمكنني ببساطة تغيير بعض الخصائص على مشروع COM / ATL الحالي للسماح باستخدام وحدات C #؟
2. كيف ستختلف هذه المكالمات الوضع المختلط في الأداء من مكالمات COM Interop؟ هل هناك تنسيق سلسلة مشترك يمكن استخدامه لمنع التحويل أو النسخ العميقة بين الوحدات النمطية؟
3. إذا تم إنشاء DLL هذا الوضع المختلط، فهل لا يزال يتخلل / استخدامه بنفس الطريقة من قبل عملاء COM، أو هل يحتاجون إلى وضع وضع مختلط؟
4. سوف تضمين CLR فرض النفقات العامة كبيرة عند تحميل كائن COM هذا؟

أنا جديد في تطوير Windows، لذا يرجى التعليق إذا كان أي شيء في بيان الأسئلة يحتاج إلى توضيح أو تصحيح.

شكرا لك مقدما.

Answer 1

كيف أذهب حول تحديد هذا؟ هل يمكنني ببساطة تغيير بعض الخصائص على مشروع COM / ATL الحالي للسماح باستخدام وحدات C #؟

إذا قمت بالتحكم بالكامل في هذا المشروع، فلن تكون تغيير هذه الإعدادات مشكلة، ثم بالتأكيد. كل ما تحتاجه هو تمكين /clr بالنسبة لهذا المشروع (في خصائص المشروع، افتح صفحة "General"، والبحث عن دعم "وقت تشغيل اللغة الشائعة"). الآن يمكنك استخدام المقابض المدارة (^) وغيرها من بت ++ / CLI البتات في مشروعك حسب الحاجة. يجب أن تواصل جميع التعليمات البرمجية الحالية المكتوبة في C ++ عادي العمل (سيتم تجميعها ل MSIL الآن، بقدر ما قدر الإمكان، ولكن ستظل دلالاتها دون تغيير).

كيف ستختلف هذه المكالمات الوضع المختلط في الأداء من مكالمات COM Interop؟ هل هناك تنسيق سلسلة مشترك يمكن استخدامه لمنع التحويل أو النسخ العميقة بين الوحدات النمطية؟

ستكون مكالمة الوضع المختلط بشكل أسرع، لأنه يستخدم اتفاقيات استدعاء أسرع، ولا تقوم بأي من أشكال التنظيم بالطريقة Interop COM (إما استخدام أنواع متوافقة بطبيعتها، أو قم بإجراء تحويلاتك الصريحة).

ليس هناك تنسيق سلسلة مشترك - المشكلة هي أن System::String كلا يخصصين ويمتلك المخزن المؤقت لها، كما يتطلب الأمر ثابتا؛ لذلك لا يمكنك إنشاء مخزن مؤقت بنفسك ثم لفه String, أو إنشاء String ثم استخدمه كمخزن مؤقت لإخراج النص إلى.

إذا تم إنشاء DLL هذا الوضع المختلط، فهل لا يزال يتخلل / استخدامه بنفس الطريقة من قبل عملاء COM، أو هل يحتاجون إلى وضع وضع مختلط؟

يمكن تربطة نفس الشيء، ولكن إذا دخلت عبر نقطة الدخول الأصلية، فسيحاول تحميل CLR في العملية، ما لم يتم تحميل المرء بالفعل. إذا كان عميل المكالمات قد تم تحميل CLR بالفعل قبل المكالمة (أو تم استدعاء العميل نفسه من التعليمات البرمجية المدارة)، فستحصل على CLR الذي تم تحميله بالفعل، مما قد يكون مختلفا عن CLR يتطلب رمزك (مثل العميل قد يكون تحميل 1.1، ويحتاج الرمز الخاص بك 2.0).

سوف تضمين CLR فرض النفقات العامة كبيرة عند تحميل كائن COM هذا؟

ذلك يعتمد على ما تحدده النفقات العامة. حجم الرمز؟ عقوبات وقت التشغيل؟ بصمة الذاكرة؟

على أي حال، فإن تحميل CLR يعني أنك تحصل على جميع آلات GC و JIT. تلك ليست رخيصة. ومع ذلك، إذا كنت بحاجة إلى الاتصال بالإمكانات المدارة في نهاية المطاف على أي حال، فلا توجد طريقة حول هذا الأمر - سوف لديك لتحميل CLR في بعض العملية للقيام بذلك. العقوبات لن تختلف بين جمعيات COM Interop و Mixed C ++ CLI.

Answer 2

لا أستطيع أن أقول الكثير عن التفاصيل مثل قضايا السلسلة، لأنني لم أستخدم هذا النهج بنشاط.

ولكن يمكنك بسهولة تناول أي واجهة COM من أي رمز C # من خلال السماح ببساطة "معالج VS" إنشاء وكيل لك، لا يوجد أي أداء مرفق عليه باستثناء الوحدة التي لديك دائما عند استدعاء COM و .NET.

الاتجاه الآخر، عليك فقط تعيين تجمعات C # الخاصة بك ComVisibleAttribute إلى True (in vs، إنه خانة اختيار بسيطة في خصائص المشروع)، ثم سيقوم المحول البرمجي تلقائيا بإنشاء واجهات COM لك. مرة أخرى، ليس هناك عقوبة أداء إضافية.

هث!