.NET Remoting真的过时了吗？

每个人都在说WCF如何取代.NET Remoting，但我想知道它的准确性如何。我还没有官方消息表明Remoting已被弃用，而且在我看来，肯定存在一些场景，其中Remoting比WCF更有意义。与远程处理有关的对象或方法都没有被弃用，即使在框架的版本4.0中也是如此。据我了解，3.5和4.0框架中的System.AddIn使用远程处理。

有人有相反的官方说法吗？

在文章“ .NET中选择通讯选项（对于3.0，因为这是该文章的最新版本）”中，它指出：

8跨应用程序域通信

如果需要在同一过程中支持不同应用程序域中对象之间的通信，则必须使用.NET远程处理。

现在，这当然是不准确的，因为可以肯定地使用WCF来跨越应用程序域边界，但这是否为该情况提供了官方建议？

更新：我向Clemens Vasters（属于拥有Remoting和WCF的团队中的人）发送了以下问题：

Clemens，我了解您是同时拥有远程处理和wcf的团队的成员，并且我有几个问题，我认为我需要参考原始资料。

首先，我有一个关于远程处理是否会消失的问题。具体来说，我们有一个相当大的应用程序，它广泛使用远程处理进行跨应用程序域内的通信，我想知道这种远程处理的使用是否被认为是“传统”。如果是这样，AppDomain.CreateInstance和朋友是否将替换为其他东西？

这是他的答复：

远程处理是.Net Framework的一部分，因此不会消失。自Windows NT 3.5 / Windows 95以来，COM一直在Windows中使用，并且一直没有消失，我也不希望很快消失。

也就是说，只有极少的开发投资用于Remoting。WCF是Remoting的后继产品，并取代了托管代码的COM / DCOM。

对于进程内跨应用程序域通信，远程处理是CLR的本机通信方式。如果看到在短时间内泵送大量数据或大量消息的性能问题，则应认真考虑WCF和NetNamedPipeBinding。

将其称为传统技术是一种更准确的描述。

http://msdn.microsoft.com/zh-CN/library/72x4h507%28VS.85%29.aspx

本主题特定于保留的旧技术，以与现有应用程序向后兼容，不建议用于新开发。现在应该使用Windows Communication Foundation（WCF）开发分布式应用程序。

更新：WCF不能区分内部/内部/进程/内部/内部应用程序域。如果在WCF中使用单机通信，则使用命名管道-使用它在几乎所有实际情况下都应具有良好的性能。

有关各种分布式通信技术的性能比较，请参见此处。

是。远程处理已弃用……它是Microsoft的官方产品。这是链接：

.NET远程处理

本文的第一行以粗体显示：

本主题特定于保留的旧技术，以与现有应用程序向后兼容，不建议用于新开发。现在应该使用Windows Communication Foundation（WCF）开发分布式应用程序。

我以为“废话”已过时，但显然他们称其为“旧版”

如果您想迁移到.NET Core，则无论如何都必须找到另一个解决方案：

.NET Remoting被确定为有问题的体系结构。它用于跨AppDomain的通信，不再受支持。另外，远程处理需要运行时支持，这维护成本很高。由于这些原因，.NET Core不支持.NET Remoting，并且我们不打算在将来增加对它的支持。

来源：https : //docs.microsoft.com/zh-cn/dotnet/core/porting/libraries#remoting

Microsoft .NET服务总线的技术负责人Clemens Vasters（这意味着Remoting和WCF都可以在本论坛帖子中讨论WCF与Remoting）。总而言之，他最终推荐了WCF，而不是Remoting。

我不确定.NET 4.0是否在内部使用远程处理，但是您可以尝试向Clemens发送问题……我确定他知道答案。

我认为现在（2015年）对于跨应用程序域也很清楚：https： //msdn.microsoft.com/zh-cn/library/vstudio/ms180984（v = vs.100）.aspx

远程处理跨AppDomains 本主题特定于保留一种旧技术，以与现有应用程序向后兼容，因此不建议用于新开发。现在应该使用Windows Communication Foundation（WCF）开发分布式应用程序。

然后，WCF也应用于跨应用程序域。