.NET Remoting 真的被弃用了吗? [英] Is .NET Remoting really deprecated?
问题描述
每个人都在说 .NET Remoting 如何被 WCF 取代，但我想知道这有多准确.我还没有看到任何关于 Remoting 被弃用的官方消息，在我看来，肯定存在 Remoting 比 WCF 更有意义的场景.没有任何与 Remoting 相关的对象或方法被弃用，即使在框架的 4.0 版中也是如此.3.5 和 4.0 框架中的 System.AddIn 使用 Remoting 也是我的理解.
Everyone is saying how .NET Remoting is being replaced by WCF, but I'm wondering just how accurate that is. I haven't seen any official word that Remoting is being deprecated, and it seems to me there are certainly scenarios where Remoting makes more sense than WCF. None of the Remoting-related objects or methods have been deprecated, even in version 4.0 of the framework. It is also my understanding that System.AddIn in the 3.5 and 4.0 frameworks use Remoting.
有没有人有任何相反的官方说法?
Does anyone have any official word to the contrary?
在文章中，在 .NET 中选择通信选项(对于 3.0，因为那是该文章的最新版本)，它指出:
In the article, Choosing Communication Options in .NET (for 3.0, as that's the latest version of that article), it states:
8 跨应用域通信
如果您需要支持同一进程内不同应用程序域中的对象之间的通信，则必须使用 .NET 远程处理.
If you need to support communication between objects in different application domains within the same process, you must use .NET remoting.
现在，这当然不准确，因为 WCF 当然可以用于跨越应用域边界，但它是否为该场景提供了官方建议?
Now, that, of course, isn't accurate, as WCF can certainly be used to cross appdomain boundaries, but is it giving the official recommendation for that scenario?
更新:我向 Clemens Vasters(他在拥有 Remoting 和 WCF 的团队中)发送了这个问题:
Update: I sent Clemens Vasters (who was on the team that owns Remoting and WCF) this question:
Clemens，我知道您所在的团队同时拥有远程处理和 wcf，而且我有几个问题，我认为我需要去寻求源头.
Clemens, I understand you're on the team that owns both remoting and wcf, and I have a couple of questions that I believe I need to go to the source for.
首先，我有一个关于远程处理是否会消失的问题.具体来说，我们有一个相当大的应用程序，它广泛地使用远程处理进行进程内跨应用程序域通信，我想知道这种远程处理的用法是否被认为是遗留的".如果是这样，AppDomain.CreateInstance 和朋友会被其他东西取代吗?
First, I have a question about whether remoting is going away. Specifically, we have a rather large application that uses remoting extensively for in-process cross-appdomain communication, and I was wondering if this usage of remoting is considered "legacy". If so, will AppDomain.CreateInstance and friends be replaced with something else?
这是他的回复:
远程处理是 .Net 框架的一部分，因此它不会消失.COM 从 Windows NT 3.5/Windows 95 开始就出现在 Windows 中，并没有消失，我也认为它不会很快消失.
Remoting is part of the .Net Framework and as such it isn't going away. COM has been in Windows since Windows NT 3.5/Windows 95 and hasn't gone away and I don't see that going away anytime soon, either.
也就是说，用于远程处理的开发投资非常少.WCF 是 Remoting 的继承者，并取代了 COM/DCOM 的托管代码.
That said, there is very minimal development investment going into Remoting. WCF is the successor of Remoting and supplants COM/DCOM for managed code.
对于进程内、跨应用域通信，远程处理是 CLR 的原生通信方式.如果您发现在短时间内抽取大量数据或大量消息的性能问题，您应该认真研究 WCF 和 NetNamedPipeBinding.
For in-process, cross-appdomain communication Remoting is the CLR's native way of communicating. If you are seeing performance issues pumping larger amounts of data or very many messages in short time, you should take a serious look at WCF and the NetNamedPipeBinding.
推荐答案
将其称为遗留技术更为准确.
Calling it a legacy technology is a more accurate description.
http://msdn.microsoft.com/en-us/library/72x4h507%28VS.85%29.aspx
此主题特定于遗产保留的技术与现有的向后兼容应用程序，不推荐为新的发展.分散式现在应该开发应用程序使用 Windows 通信基金会(WCF).
This topic is specific to a legacy technology that is retained for backward compatibility with existing applications and is not recommended for new development. Distributed applications should now be developed using the Windows Communication Foundation (WCF).
更新:WCF 不区分inter/intra/process/inter/intra-appdomain.如果您在 WCF 中使用单机通信，则使用命名管道 - 使用它应该可以在几乎所有实际场景中提供良好的性能.
Update: WCF doesn't distinguish between inter/intra/process/inter/intra-appdomain. If you are using single machine communication in WCF you use named pipes- using it should give good performance in virtually all realistic scenarios.
有关各种分布式通信技术的性能比较请参见此处.
For a performance comparison of various distributed communication technologies see here.
这篇关于.NET Remoting 真的被弃用了吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
