WCF also provides flexibility. By just changing some config (binding) you can have the same service on some other machine instead of IPC on same machine. Therefore your code remains flexible.
If it's on a single machine, Named Pipes gives you better performance and can be implemented with the remoting infrastructure as well as WCF. Or you can just directly use System.IO.Pipes.
If you mean inter-process communication, I used .NET Remoting without any problem so far. If the two processes are on the same machine, the communication is quite fast.
Named Pipes are definitely more efficient, but they require the design of at least a basic application protocol, which might not be feasible. Remoting allows you to invoke remote methods with ease .
If you are using the .NET Framework 3.0 or above, I would use WCF. Using WCF, you can use different bindings depeneding on the trade-off between performance/interop/etc. that you need.
If performance isn't critical and you need interop with other Web Service technologies, you will want to use the WS-HTTP binding. For your case, you can use WCF with either a net-tcp binding, or a named-pipe binding. Either should work.
My personal take is that the WCF approach is more clean as you can do Contract-Driven services and focus on messages, not objects (I'm making a generalization here based on the default programming models of WCF/.NET Remoting). I don't like sending objects across the wire because a lot of semantic information gets lost or is not clear. When all you are doing is sending a message like you are with WCF, it becomes easier to separate your concerns between communication and the classes/infrastructure that a single node is composed of.
The WCF and .NET Remoting are really comparable in performance. The differences are so small (measuring client latency) that it does not matter which one is a bit faster. WCF though has much better server throughput than .NET Remoting. If I would start completely new project I would chose the WCF. Anyway the WCF does much more than Remoting and for all those features I love it.
.net remoting is built into .net to do inner process communication. If you use that, they will continue to support and possibly enhance it in future versions. Named pipes doesn't give you the promise of enhancements in future versions of .net
发布评论
评论（8）
.NET Framework 2.0 中的远程处理为同一计算机内的进程间通信提供了IPC 通道。
Remoting in .NET Framework 2.0 provides the IPC channel for inter-process communication within the same machine.
WCF 还提供灵活性。 只需更改一些配置（绑定），您就可以在其他机器上使用相同的服务，而不是在同一台机器上使用 IPC。 因此您的代码保持灵活。
WCF also provides flexibility. By just changing some config (binding) you can have the same service on some other machine instead of IPC on same machine. Therefore your code remains flexible.
.Net 远程处理本身并不是一个协议。 它允许您选择要使用的协议：SOAP、命名管道等。
.Net remoting isn't a protocol in and of itself. It lets you pick which protocal to use: SOAP, named-pipes, etc.
如果在单台计算机上，命名管道可为您提供更好的性能，并且可以使用 远程基础设施 以及 WCF。 或者您可以直接使用 System.IO.Pipes。
If it's on a single machine, Named Pipes gives you better performance and can be implemented with the remoting infrastructure as well as WCF. Or you can just directly use System.IO.Pipes.
如果你指的是进程间通信，到目前为止我使用 .NET Remoting 没有任何问题。 如果两个进程在同一台机器上，通信速度相当快。
命名管道肯定更高效，但它们至少需要设计一个基本的应用程序协议，这可能不可行。 远程处理允许您轻松调用远程方法。
If you mean inter-process communication, I used .NET Remoting without any problem so far. If the two processes are on the same machine, the communication is quite fast.
Named Pipes are definitely more efficient, but they require the design of at least a basic application protocol, which might not be feasible. Remoting allows you to invoke remote methods with ease .
如果您使用.NET Framework 3.0或更高版本，我会使用WCF。 使用 WCF，您可以根据性能/互操作等之间的权衡使用不同的绑定。 你需要的。
如果性能并不重要并且您需要与其他 Web 服务技术进行互操作，那么您将需要使用 WS-HTTP 绑定。 对于您的情况，您可以将 WCF 与 net-tcp 绑定或命名管道绑定结合使用。 两者都应该有效。
我个人的看法是，WCF 方法更干净，因为您可以执行契约驱动的服务并专注于消息，而不是对象（我在这里基于 WCF/.NET Remoting 的默认编程模型进行概括）。 我不喜欢通过网络发送对象，因为很多语义信息会丢失或不清楚。 当您所做的只是像使用 WCF 一样发送消息时，您可以更轻松地将通信和单个节点组成的类/基础设施之间的关注点分开。
If you are using the .NET Framework 3.0 or above, I would use WCF. Using WCF, you can use different bindings depeneding on the trade-off between performance/interop/etc. that you need.
If performance isn't critical and you need interop with other Web Service technologies, you will want to use the WS-HTTP binding. For your case, you can use WCF with either a net-tcp binding, or a named-pipe binding. Either should work.
My personal take is that the WCF approach is more clean as you can do Contract-Driven services and focus on messages, not objects (I'm making a generalization here based on the default programming models of WCF/.NET Remoting). I don't like sending objects across the wire because a lot of semantic information gets lost or is not clear. When all you are doing is sending a message like you are with WCF, it becomes easier to separate your concerns between communication and the classes/infrastructure that a single node is composed of.
WCF是最好的选择。 它支持一个数字不同的传输机制（包括 命名 管道）并且可以完全由配置驱动。 我强烈建议您看看 WCF。
这是一个博客，它执行 WCF 与 Remoting 性能比较。
引用博客中的一段话：
WCF 的 MSDN 部分
WCF is the best choice. It supports a number of different transport mechanisms (including Named Pipes) and can be completely configuration driven. I would highly recommend that you take a look at WCF.
Here is a blog that does a WCF vs Remoting performance comparison.
A quote from the blog:
MSDN Section for WCF
.net 远程处理内置于 .net 中以进行内部进程通信。 如果您使用它，他们将继续支持并可能在未来版本中增强它。 命名管道并不承诺在 .net 的未来版本中提供增强功能
.net remoting is built into .net to do inner process communication. If you use that, they will continue to support and possibly enhance it in future versions. Named pipes doesn't give you the promise of enhancements in future versions of .net