Mar*_*ark 92 .net wcf remoting
每个人都在说如何用WCF取代.NET Remoting,但我想知道它是多么准确.我还没有看到任何关于Remoting被弃用的官方消息,在我看来,Remoting肯定比WCF更有意义.即使在框架的4.0版本中,也没有弃用与Remoting相关的对象或方法.我的理解是3.5和4.0框架中的System.AddIn使用Remoting.
有没有人有任何相反的官方消息？
在文章" 选择.NET中的通信选项(3.0版,因为那是该文章的最新版本)"中,它指出:
8跨应用程序域通信
如果需要在同一进程中支持不同应用程序域中的对象之间的通信,则必须使用.NET远程处理.
现在,这当然不准确,因为WCF当然可以用于跨越appdomain边界,但它是否正在为该场景提供官方建议？
更新:我发送了Clemens Vasters(谁是拥有Remoting和WCF的团队)这个问题:
Clemens,我知道你是拥有远程控制和wcf的团队,我有几个问题,我认为我需要去找源代码.
首先,我有一个关于远程处理是否会消失的问题.具体来说,我们有一个相当大的应用程序,它广泛使用远程处理进行跨域appdomain通信,我想知道远程处理的这种用法是否被认为是"遗留".如果是这样,AppDomain.CreateInstance和朋友会被其他东西取代吗？
这是他的回复:
远程处理是.Net框架的一部分,因此它不会消失.自Windows NT 3.5/Windows 95以来,COM一直在Windows中,并且还没有消失,我也不认为它会很快消失.
也就是说,Remoting的开发投资非常少.WCF是Remoting的继承者,并取代了托管代码的COM/DCOM.
对于进程内,跨域应用程序通信远程处理是CLR的本地通信方式.如果您发现在短时间内抽取大量数据或大量消息的性能问题,您应该认真考虑WCF和NetNamedPipeBinding.
Ric*_*dOD 54
将其称为传统技术是一种更准确的描述.
http://msdn.microsoft.com/en-us/library/72x4h507%28VS.85%29.aspx
本主题特定于为保持与现有应用程序向后兼容而保留的旧技术,不建议用于新开发.现在应该使用Windows Communication Foundation(WCF)开发分布式应用程序.
更新:WCF不区分inter/intra/process/inter/intra-appdomain.如果您在WCF中使用单机通信,则使用命名管道 - 使用它应该在几乎所有实际场景中都能提供良好的性能.
有关各种分布式通信技术的性能比较,请参见此处.
Jus*_*ner 10
是.Remoting已被弃用......而且它是微软官方的.这是链接:
文章的第一行用粗体表示:
本主题特定于为保持与现有应用程序向后兼容而保留的旧技术,不建议用于新开发.现在应该使用Windows Communication Foundation(WCF)开发分布式应用程序.
我认为这句话被"弃用"但显然他们称之为"遗产"
小智 7
如果您想迁移到 .NET Core，则无论如何都必须找到另一种远程处理解决方案：
.NET Remoting 被确定为有问题的架构。它用于不再支持的跨 AppDomain 通信。此外，远程处理需要运行时支持，维护成本很高。由于这些原因，.NET Core 不支持 .NET Remoting，我们不打算在未来添加对它的支持。
来源：https : //docs.microsoft.com/en-us/dotnet/core/porting/libraries#remoting