对于.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

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 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 isn't a protocol in and of itself. It lets you pick which protocal to use: SOAP, named-pipes, etc.

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:

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.

MSDN Section for WCF

Remoting in .NET Framework 2.0 provides the IPC channel for inter-process communication within the same machine.

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 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.