每个人都在说如何用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.