WCFが最適です。 さまざまなトランスポートメカニズムの数 （ 含む名前付きパイプ ）をサポートし、完全に構成駆動型にすることができます。 WCFをご覧になることを強くお勧めします。
WCFとRemotingのパフォーマンス比較 を行うブログを次に示します。
ブログからの引用：
WCFと.NET Remotingのパフォーマンスは実際に同等です。違いは非常に小さいため（クライアントの待ち時間を測定）、どちらが少し速いかは関係ありません。ただし、WCFのサーバースループットは.NET Remotingよりもはるかに優れています。完全に新しいプロジェクトを開始する場合、WCFを選択します。とにかく、WCFはRemotingよりもはるかに多くの機能を備えており、これらすべての機能について私は気に入っています。
単一のマシン上にある場合、名前付きパイプを使用するとパフォーマンスが向上し、WCFと同様に リモートインフラストラクチャ を使用して実装できます。または、直接 System.IO.Pipes を使用できます。
プロセス間の通信を意味する場合、これまでのところ問題なく.NET Remotingを使用しました。 2つのプロセスが同じマシン上にある場合、通信は非常に高速です。
名前付きパイプは間違いなくより効率的ですが、少なくとも基本的なアプリケーションプロトコルの設計が必要であり、これは実行不可能な場合があります。リモート処理を使用すると、リモートメソッドを簡単に呼び出すことができます。
.NET Framework 3.0以降を使用している場合は、WCFを使用します。 WCFを使用すると、パフォーマンス/相互運用性などのトレードオフに応じて異なるバインディングを使用できます。必要なもの。
パフォーマンスが重要ではなく、他のWebサービステクノロジとの相互運用が必要な場合は、WS-HTTPバインディングを使用する必要があります。あなたのケースでは、WCFをnet-tcpバインディングまたは名前付きパイプバインディングで使用できます。どちらも動作するはずです。
私の個人的な見解は、契約駆動型のサービスを実行し、オブジェクトではなくメッセージに焦点を当てることができるため、WCFアプローチがよりクリーンであるということです（ここでは、WCF/.NET Remotingの既定のプログラミングモデルに基づいて一般化を行っています）。多くのセマンティック情報が失われるか、明確ではないため、ネットワーク経由でオブジェクトを送信するのは好きではありません。 WCFのようにメッセージを送信するだけの場合、通信と単一ノードを構成するクラス/インフラストラクチャとの間の懸念を簡単に分離できます。
.NET Framework 2.0のリモート処理は、同じマシン内のプロセス間通信にIPCチャネルを提供します。
WCFは柔軟性も提供します。構成（バインディング）を変更するだけで、同じマシンでIPCの代わりに他のマシンで同じサービスを使用できます。したがって、コードの柔軟性は維持されます。
.Netリモーティングは、それ自体はプロトコルではありません。 SOAP、名前付きパイプなど、使用するプロトコルを選択できます。
.netリモート処理は、内部プロセス通信を行うために.netに組み込まれています。あなたがそれを使用する場合、彼らは将来のバージョンでそれをサポートし、おそらく強化するでしょう。名前付きパイプは、将来のバージョンの.netでの機能強化の見込みを提供しません