私はある種類のタスクマネージャーとして機能するアプリケーションを作成します。安定性の理由から、私はスレッドを使用せず、代わりにプロセスを使用します。私はいくつかのサードパーティ製のライブラリやCOMサーバを扱わなければならず、常に安定しているとは限らず、重大なクラッシュが発生することがあります。これは（もちろん）タスクマネージャには影響しませんプロセスとの通信における最善のアプローチ
プロセスを使用する際の問題は、それらと通信する方法ですか？プロセスはf.e. x秒ごとに何をしているのかのステータスを返します。
私は、プロセスごとに別のポートでTCPを使用することを考えていましたが、これを行うにはこれが最善の方法ですか？
パイプを使用するとよいでしょう。 System.IO.Pipes名前空間を見てください。
名前付きパイプがおそらくより効率的です。 WCFを見てみましょう：
私は同意しますが、私の解決策ではサービスを利用できません。それはプロセスである必要があります。 –
各プロセスはサービスを公開することができますが、問題は表示されません –
私はあなたがインストルメンテーションを見てすべきだと思う：
http://msdn.microsoft.com/en-us/magazine/cc300488.aspx
ようなポートまたはWCFで話しているような任意の他のアプローチは、ルートを推測することができますレイヤーを追加します問題の原因をもっと難しくする。それはInstrumentationと比較してパフォーマンスが優れています。 WMIは、高性能な監視を中心に構築されています。さらに、これは運用上、プロセスの正常性を監視するための管理ツールとして使用されるため、最良のアプローチです。
WCFを使用できます（NetNamedPipeBindingバインディングを使用）。
そして多分にあなたのプロセスを実行するためのAppDomainを考える。
+1 for AppDomains – kenny
私は同意しますが、私の解決策ではサービスを利用できません。それはプロセスである必要があります。 –
@marc、appdomains！= services –
を私もWCFと名前付きパイプとなるだろうが、それを補うyou're場合は、シグナリングと（メモリマップファイル）共有メモリを使用することができます。それは速いですが、コードの複雑さの価値はないかもしれません。
いくつかのサンプルコードではblog postをご覧ください。
必要な通信は非常に限られているため、この作業には最も理想的なソリューションではありません。 –
最初はこれが私の必要とするものです。追加設定が不要でシンプルです。 –