C ++（MFC）アプリとC＃の間でデータを渡す

StackOverflow https://stackoverflow.com/questions/184777

  •  06-07-2019
  •  | 
  •  

質問

モノリシックなMFC GUIアプリがあり、C ++での寿命が近づいています。 C＃で新しい機能を構築し、各アプリ間でデータを受け渡すことを計画しています。

質問：C ++とC＃の間でデータを受け渡すための最良の方法は何ですか？

注：
両端にはGUIフロントエンドがあり、おそらくIdのような単純なデータを渡すだけでよく、おそらく他のアプリに使用するプロセス/機能を示すメカニズムが必要です。
たとえば、アプリケーションの1つはC＃のCRMシステムで、グリッドの行がダブルクリックされると、customerIdとメッセージを渡し、MFCアプリの顧客フォームでその顧客を開きます。

少し調べたところ、オプションはWindowsメッセージング、メモリマッピング、名前付きパイプ、またはWindowsソケットなどです。この段階では、名前付きパイプに傾いていますが、他のアドバイスやヒント、または他の人々の経験に本当に感謝しています。

役に立ちましたか？

解決

個人的には、名前付きパイプはC ++側からも.NET側のSystem.IO.Pipesからも使いやすいので、名前付きパイプのようなものを使用することを考えています。

また、時間とともにアプリの他の.NET以外のビットを交換することを計画している場合、おそらく最も抵抗の少ないパスになります。

他のヒント

選択してください：

  • ファイル
  • 名前付きパイプ<！> lt;-私の推薦
  • 共有メモリ
  • ソケット
  • COM
  • Windowsメッセージ

名前付きパイプを使用する理由

  • FIFOで無料で作業する方法を提供します（ソケットと同様ですが、共有メモリとは異なります）
  • 両方の方法で簡単に通信できます
  • すべてのプラットフォームで十分にサポートされています
  • 使いやすい
  • 信頼できるデータの受け渡しと配信
  • ブロックおよび非ブロックにすることができます
  • （ソケットとは異なり）削除せずにデータを読み取ることができます
  • 簡単に3つ目のアプリを含めるように拡張できます。

.NetではSystem.IO.Pipesを使用します。

C ++では、CreateNamedPipeとCreateFileを使用します。

マネージドサイドからP / Invokeを使用することもできます-これは、MFCアプリにC APIがある場合に役立ちます。また、どちらの側からもCOMを使用できます。

リストするオプションは確かに有効ですが、COMを検討することもできます。

ソケット（TCP）を使用します-MFCと.NETは両方とも直接サポートしています。

本当に2つのプロセスが必要ですか？

アンマネージドC ++およびマネージドC＃コードは同じプロセスで完全に動作でき、マネージドC ++ / CLIの小さなレイヤーで、プロセス間通信の複雑さを単純な関数呼び出しで置き換えることができます。

私の選択は、標準のウィンドウメッセージ（WM_FOOなど）またはDCOMのいずれかです：

  • メッセージは、通信が非常に単純で、設定のオーバーヘッドが最小限である限り機能します。通信をメッセージごとに1つまたは2つの整数に要約できる場合、これはおそらく開始するのに適した場所です。両方のアプリが既にウィンドウ化されたアプリケーションである場合は、両方ともメッセージループを既に持っているので、あなたはすでにほとんどの方法にいます。

  • DCOMはより多くのプログラマのオーバーヘッドを必要としますが、より豊富なインターフェイスを定義でき、複雑なメッセージをバイナリ形式に変換したり、バイナリ形式から変換したりする必要がないという点で便利です。このルートに進むと、CoRegisterClassObjectはDCOMを介してオブジェクトを公開するための出発点になります。私はこれをC＃アプリから試したことはありませんが、原則的には完全に可能であるはずです

レガシーアプリのソースがあると仮定して、すべての<！> quot; workhorse <！> quot;をコンパイルできないかどうかを確認します。 DLLとしてコード化し、そこから個々の関数/ウィンドウを呼び出します。動作するようになったら、必要な関数をマネージC ++ラッパーで簡単に記述し、C＃コードから呼び出すことができます。運がよければ、プロセス全体が1日未満で完了します。

アプリが実行されるすべてのシステムに存在する.NETフレームワークを心配する必要がない場合はC ++ / CLI、そうでない場合はCOMと言います。ただし、最も快適で使い慣れているものに依存します。 C ++ / CLIとCOMの既存の「関数呼び出し」構造（他のプロトコルで構築するのではなく）が好きですが、それは私だけです。

現在、主に.NETが存在しない場合でもフォールバックで機能する必要があるため、いくつかの.NETコンポーネント機能を追加するためにCOMを使用していますが、それは最大の展開が望ましい私のニーズに固有です。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top