8

私は、AppDomain 間のプロセス内およびプロセス間のマシン内通信を必要とするプロジェクトに取り組んでいます。はい... わかっています... NET Remoting はレガシー テクノロジと広く見なされていますが、私は 2 つの非常に特殊な問題に直面しています。

1) AppDomain 間のプロセス内通信

私が取り組んでいるアプリケーションが起動し、複数のアドインで検索してロードする必要があります。各アドインを個別の AppDomain にロードしたいと考えています。AppDomain に各 Addin インスタンスを作成し、ある時点でこのインスタンスのいくつかのインターフェイス メソッドを呼び出す方法が必要です。ここでは NET Remoting が唯一の方法ですよね? さらに、System.Addins パラダイムを適用したい場合は、明らかに NET Remoting のみに基づいており、古いものとしてマークされていません...

2) プロセス間マシン内通信

ここでは、アプリケーションから確実に WCF サービスを公開し、名前付きパイプを使用してクライアントからこのサービスを呼び出すことができます。

私が本当にやりたいことは、アプリケーションからオブジェクト モデルを公開することです。これにより、Excel によって公開される OLE/COM オートメーション オブジェクト モデルと同様に、一部の NET クライアントからアプリケーションを自動化できます。すべての COM クライアントは、Excel.Application へのオブジェクト参照を取得し、開いているドキュメントを照会したり、新しいドキュメントを開いたりすることができます。

WCF は、プラットフォームに依存しない方法で通信するのに適していると思います。しかし、この場合、同じマシン上の Net クライアントから Net アプリケーションに通信するだけで済みます。WCF サービスの哲学では、オブジェクト、コレクション、フィールド、静的メンバー、メソッドのオーバーロードを含むリッチ オブジェクト モデルを公開することはできないと思います... それとも間違っていますか?

私の下手な英語とおそらく初心者の質問をお許しください。

4

1 に答える 1

2

ここで同様の質問に対する回答を読むことができます: Is .NET Remoting really deprecated?

最近、比較的単純な双方向のプロセス間通信に .NET Remoting を使用したことを付け加えておきますが、すべてがほぼシームレスに行われたため、Microsoft によって積極的にサポートされていない年月が経っても、まだ非常に使用可能であると言えます。

COM に関しては、COM クライアントから製品にアクセスできるようにするという強い要件がある場合は、COM 相互運用機能を介して COM インターフェイスを明示的に実装することをお勧めします。また、COM と .NET Remoting を一緒に使用することに関する興味深い記事があります

于 2013-09-04T07:17:44.530 に答える