每个人都在说如何用WCF取代.NET Remoting，但我想知道它是多么准确。我还没有看到任何关于Remoting被弃用的官方消息，在我看来，Remoting肯定比WCF更有意义。即使在框架的4.0版本中，也没有弃用与Remoting相关的对象或方法。我也理解，3.5和4.0框架中的System.AddIn使用Remoting。
有没有人有任何相反的官方消息？
在文章中，Choosing Communication Options in .NET（对于3.0，因为这是该文章的最新版本），它指出：
8跨应用程序域通信
如果需要在同一进程中支持不同应用程序域中对象之间的通信，则必须使用.NET远程处理。
现在，这当然不准确，因为WCF当然可以用于跨越appdomain边界，但它是否正在为该场景提供官方建议？
更新：我发送了Clemens Vasters（谁是拥有Remoting和WCF的团队）这个问题：
Clemens，我知道你是拥有远程控制和wcf的团队，我有几个问题我认为我需要去找源。
首先，我有一个关于远程处理是否会消失的问题。具体来说，我们有一个相当大的应用程序，它广泛使用远程处理进行跨域appdomain通信，我想知道远程处理的这种用法是否被认为是“遗留”。如果是这样，AppDomain.CreateInstance和朋友会被其他东西替换吗？
这是他的回复：
远程处理是.Net Framework的一部分，因此它不会消失。自从Windows NT 3.5 / Windows 95以来，COM一直在Windows中，并且没有消失，我也不认为它会很快消失。
也就是说，Remoting的开发投资非常少。 WCF是远程处理的继承者，并取代了托管代码的COM / DCOM。
对于进程内，跨appdomain通信远程处理是CLR的本地通信方式。如果您发现在短时间内抽取大量数据或大量消息的性能问题，您应该认真考虑WCF和NetNamedPipeBinding。
答案 0 :(得分：54)
将其称为传统技术是一种更准确的描述。
http://msdn.microsoft.com/en-us/library/72x4h507%28VS.85%29.aspx
本主题特定于遗产 保留的技术 向后兼容现有的 应用程序，不建议使用 为了新的发展。分散式 现在应该开发应用程序 使用Windows通信 基金会（WCF）。
更新：WCF不区分inter / intra / process / inter / intra-appdomain。如果您在WCF中使用单机通信，则使用命名管道 - 使用它应该在几乎所有实际场景中都能提供良好的性能。
用于各种分布式通信技术的性能比较see here。
答案 1 :(得分：10)
是。 Remoting已被弃用......而且它是微软官方的。这是链接：
文章的第一行用粗体表示：
本主题特定于为了与现有应用程序向后兼容而保留的旧技术，而不是 推荐用于新开发。现在分布式应用程序 使用Windows Communication Foundation（WCF）开发。
我认为这句话被“弃用”，但显然他们称之为“遗产”
答案 2 :(得分：4)
如果您想迁移到.NET Core，则必须找到另一种解决方案 仍要进行远程处理：
.NET Remoting被确定为有问题的体系结构。它用于跨AppDomain的通信，不再受支持。另外，远程处理需要运行时支持，这维护成本很高。由于这些原因，.NET Core不支持 .NET Remoting，因此我们不打算在将来增加对它的支持。
来源：https://docs.microsoft.com/en-us/dotnet/core/porting/libraries#remoting
答案 3 :(得分：2)
Microsoft .NET Service Bus的技术负责人Clemens Vasters（这意味着Remoting和WCF）在this forum post中讨论了WCF与Remoting的关系。总结一下这篇文章他最后推荐WCF而不是Remoting。
我不确定.NET 4.0是否在内部使用远程处理，但您可以尝试向Clemens发送问题......我确信他知道答案。
答案 4 :(得分：2)
我认为现在（2015年）即使是交叉应用它也很清楚 域： https://msdn.microsoft.com/en-us/library/vstudio/ms180984(v=vs.100).aspx
远程登录AppDomains 本主题特定于遗留问题 保留用于向后兼容现有技术的技术 应用程序，不建议用于新开发。分散式 现在应该使用Windows Communication开发应用程序 基金会（WCF）。
然后，WCF也应该用于跨应用程序域。