WCF是最好的选择，它支持a number of different transport mechanisms（includingNamedPipes），并且可以完全配置驱动，我强烈推荐你看一下WCF。
这是一个博客，做了一个WCF vs Remoting performance comparison。
博客中的一段话：
WCF和.NET Remoting在性能上是相当的。差别很小（测量客户端延迟），所以哪一个更快一点并不重要。WCF比.NET Remoting有更好的服务器吞吐量。如果我开始一个全新的项目，我会选择WCF。无论如何，WCF比Remoting做得更多，对于所有这些功能，我喜欢它。
MSDN Section for WCF

如果是在一台机器上，命名管道可以提供更好的性能，并且可以用remoting infrastructure和WCF来实现，或者你可以直接使用System.IO.Pipes。

如果你指的是进程间的通信，到目前为止我使用.NET Remoting没有任何问题，如果两个进程在同一台机器上，通信速度相当快。
命名管道无疑更高效，但它们至少需要设计一个基本的应用程序协议，这可能是不可行的。远程处理允许您轻松地调用远程方法。

如果你使用的是.NET Framework 3.0或更高版本，我会使用WCF。使用WCF，你可以使用不同的绑定，这取决于你需要的性能/互操作性/等等之间的权衡。
如果性能不是很重要，并且需要与其他Web服务技术互操作，则需要使用WS-HTTP绑定。对于您的情况，可以将WCF与net-tcp绑定或命名管道绑定一起使用。两者都可以。
我个人认为，WCF方法更简洁，因为您可以执行契约驱动的服务，并且可以关注消息，而不是对象（我在这里基于WCF/.NET Remoting的默认编程模型做了一个概括）。我不喜欢通过网络发送对象，因为很多语义信息会丢失或不清楚。当你所做的只是像使用WCF那样发送消息时，将通信和组成单个节点的类/基础结构之间的关注分开变得更加容易。

NET Framework 2.0中的远程处理为同一台计算机内的进程间通信提供了IPC通道。

WCF还提供了灵活性。通过改变一些配置（绑定），你可以在其他机器上拥有相同的服务，而不是在同一台机器上拥有IPC。因此你的代码保持了灵活性。

.Net远程处理本身并不是一个协议。它允许您选择要使用的协议：SOAP、命名管道等

net remoting内置于.net中以进行内部进程通信。如果您使用它，他们将继续支持它，并可能在将来的版本中增强它。命名管道并不给予在将来的.net版本中进行增强