.NET Remotingは本当に非推奨ですか？
誰もが.NET RemotingがWCFに置き換えられていると言っていますが、それがどれほど正確か疑問に思っています。Remotingが廃止されるという公式の言葉は見たことがありません。また、RemotingがWCFよりも理にかなっているシナリオは確かにあるようです。フレームワークのバージョン4.0であっても、Remoting関連のオブジェクトやメソッドは廃止されていません。3.5および4.0フレームワークのSystem.AddInがRemotingを使用することも私の理解です。 反対に公式の言葉はありますか？ 記事「.NETでの通信オプションの選択（3.0の場合、それはその記事の最新バージョンであるため）」では、次のように述べています。 8クロスアプリケーションドメイン通信 同じプロセス内の異なるアプリケーションドメインにあるオブジェクト間の通信をサポートする必要がある場合は、.NETリモート処理を使用する必要があります。 もちろん、WCFは確かにアプリドメインの境界を越えるために使用できるため、これは正確ではありませんが、そのシナリオに対する公式の推奨事項ですか？ 更新：私はClemens Vasters（RemotingとWCFを所有するチームに属していた）に次の質問を送信しました。 クレメンス、あなたがリモーティングとwcfの両方を所有するチームに所属していることを理解しています。また、ソースに移動する必要があると思う質問がいくつかあります。 最初に、リモート処理がなくなるかどうかについて質問があります。具体的には、プロセス内のアプリドメイン間通信でリモート処理を広範囲に使用するかなり大きなアプリケーションがあり、このリモート処理の使用が「レガシー」と見なされているのかと思いました。もしそうなら、AppDomain.CreateInstanceと友達は他のもので置き換えられますか？ これは彼の返事です： リモート処理は.Net Frameworkの一部であるため、廃止されません。COMは、Windows NT 3.5 / Windows 95以降Windowsに組み込まれており、なくなっていないため、すぐになくなることもありません。 とはいえ、Remotingへの開発投資はごくわずかです。WCFはRemotingの後継であり、マネージコードのCOM / DCOMの後継です。 インプロセスのアプリドメイン間通信の場合、リモート処理はCLRのネイティブな通信方法です。大量のデータまたは非常に多くのメッセージを短時間でポンプするパフォーマンスの問題が発生している場合は、WCFとNetNamedPipeBindingを真剣に検討する必要があります。