تمرير البيانات بين C++ (MFC) التطبيق و C#
https://stackoverflow.com/questions/184777
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
لدينا مجموعة متجانسة MFC واجهة المستخدم الرسومية التطبيق الذي شارف على نهاية حياته في C++.ونحن نخطط لبناء وظائف جديدة في C# و تمرير البيانات بين كل التطبيق.
السؤال هو:ما هو أفضل نهج في تمرير البيانات بين C++ و C# ؟
ملاحظات:
كلا الطرفين سوف يكون لها واجهة المستخدم الرسومية الواجهة الأمامية وربما تحتاج فقط لتمرير بيانات بسيطة مثل Id وربما يكون آلية حيث أنها تشير إلى التطبيق الأخرى ما هي العملية/وظائف للاستخدام.
على سبيل المثال واحدة من تطبيقات نظام إدارة علاقات العملاء في C# التي عند صف في الشبكة هو النقر المزدوج تمرير يقول "معرف العميل" و رسالة مفتوحة أن العملاء في العملاء شكل MFC التطبيق.
فعلت القليل من البحث على خيارات يبدو أن مراسلات Windows تعيين ذاكرة, أنابيب الاتصال المسماة أو شيء مثل Windows Sockets.في هذه المرحلة نحن يميل نحو ممرات لكن نقدر لك نصيحة أخرى أو نصائح أو تجارب الشعوب الأخرى.
المحلول
وأنا شخصيا سأكون تفكر في استخدام شيء من هذا القبيل أنابيب يدعى أنها سهلة الاستخدام من جانب C ++ وSystem.IO.Pipes على الجانب. NET أيضا.
وسيكون أيضا أن يكون مسار ربما أقل قدر من المقاومة إذا كنت تخطط لاستبدال البتات. NET الأخرى غير من التطبيق مع مرور الوقت.
نصائح أخرى
اختيار الخاص بك:
- الملفات
- أنابيب الاتصال المسماة <-- توصيتي
- الذاكرة المشتركة
- مآخذ
- COM
- رسائل Windows
لماذا سميت الأنابيب ؟
- يعطيك الوارد أولا يصرف أولا طريقة العمل مجانا (مثل مآخذ ، ولكن ليس مثل الذاكرة المشتركة)
- يمكن التواصل بسهولة في كلا الاتجاهين
- مدعومة بشكل جيد على جميع المنصات
- سهلة الاستخدام
- بيانات موثوقة يمر والتسليم
- يمكن حجب وعدم حجب
- يمكن قراءة البيانات دون إزالة (على عكس مآخذ)
- يمكن توسيعها لتشمل ثلث التطبيق بسهولة.
في .صافي فقط استخدام النظام.IO.الأنابيب.
في C++ استخدام CreateNamedPipe و CreateFile.
ويمكنك أيضا استخدام P / استدعاء من الجانب تمكنت - وهذا من شأنه أن يكون مفيدا إذا كان التطبيق MFC لديه API C. كما يمكنك استخدام COM من أي من الجانبين.
والخيارات لك قائمة هي بالتأكيد صحيح، ولكن هل يمكن أن تنظر أيضا في COM.
وكنت استخدام مآخذ (TCP) - على حد سواء MFC و. NET على الدعم المباشر لهم
.هل كنت حقا بحاجة عمليتين؟
وغير المدارة C ++ وتمكن C # رمز قادر تماما على العمل في نفس العملية، مع وجود طبقة صغيرة من تمكن C ++ / CLI، هل يمكن أن تحل محل تعقيد اتصال interprocess مع المكالمات وظيفة بسيطة.
بلدي يختار إما القياسية نافذة الرسائل (على سبيل المثالWM_FOO) أو DCOM:
رسائل العمل طالما أن التواصل هو بسيط جدا و النفقات العامة في إعداد عليه هو الحد الأدنى.إذا كان يمكنك غلي البلاغ إلى واحد أو اثنين من الاعداد الصحيحه في الرسالة أن هذا ربما يكون مكان جيد للبدء.إذا كان كل من تطبيقات بالفعل إطارات التطبيقات كلاهما بالفعل رسالة الحلقات, لذلك كنت بالفعل معظم الطريق هناك.
DCOM يتطلب الكثير من مبرمج النفقات العامة ، ولكن من الجميل أن يمكنك تحديد أكثر ثراء واجهة وتجنب الحاجة إلى تحويل الرسائل المعقدة من شكل ثنائي.إذا كنت تذهب في هذا الطريق ، CoRegisterClassObject هو نقطة انطلاق النشر كائن عبر DCOM.لقد حاولت أبدا القيام بذلك من C# التطبيق ، ولكن من حيث المبدأ ينبغي أن يكون من الممكن تماما
وعلى افتراض أن يكون لديك المصدر إلى التطبيق تراث، معرفة ما إذا كان لا يمكنك تجميع كل "العمود الفقري" كود باعتباره DLL، ثم استدعاء وظائف فردية / ويندوز من هناك. وبمجرد الانتهاء من هذا العمل، يمكنك ببساطة الكتابة المدارة مغلفة C ++ حول الوظائف التي تحتاج إليها، واستدعاء تلك من هاتفك C # رمز. العملية برمتها يمكن أن تستغرق أقل من يوم واحد، إذا كنت محظوظا.
وأود أن أقول C ++ / CLI إذا لم يكن لديك ما يدعو للقلق صافي الإطار الموجودة على كافة أنظمة سيتم تشغيل التطبيق على وCOM خلاف ذلك. وسوف تعتمد حقا على ما كنت أكثر راحة ودراية، وإن كان. أنا أحب "استدعاء دالة" الهيكل الحالي للC ++ / CLI وCOM (بدلا من بنائه مع البروتوكولات الأخرى)، ولكن هذا مجرد لي.
وأنا حاليا باستخدام COM لإضافة بعض الوظائف المكون .NET، ويرجع ذلك أساسا إلى ضرورة لا تزال تعمل مع fallbacks إذا الصافي لم يكن موجودا، ولكن هذا محدد لاحتياجاتي حيث الحد الأقصى نشر هو الأفضل.
