所以目前我的公司正在使用 TCP/IP 连接在服务器程序和客户端程序之间进行通信，现在我们正在使用 System.RunTime.Remoting 建立这个连接，它既笨重又不那么可靠。它是在大约 5 年前构建的，该模型不断被重复使用，并且开始传播一些问题、使用的端口、拒绝连接等。
我正在尝试查找一些有关如何将其更改为 WCF 的资源，但我不确定我在寻找什么或应该搜索什么。
如果您想了解更多关于实际使用它的信息，我可以详细介绍，但我需要提取代码并确保我完整地解释它。
谢谢！
【问题讨论】：
Mikael 已经在他的帖子中谈到了大部分相关点 - 选择 netTcpBinding，它速度非常快，在 LAN 环境中工作得非常好，并且具有您应该需要的所有功能。
主要区别在于思维方式的改变：在远程处理中，您基本上是在使用“远程对象”——您或多或少地远程控制另一台机器上的现有 .NET 对象。
WCF 从根本上来说是非常不同的：您有一个服务器和一个客户端，它们共享的不仅仅是服务契约（方法描述）和数据契约（传递数据的描述）。在运行时，您调用客户端上的代理，WCF 运行时拦截该调用，对其进行序列化（包括所有参数），然后通过线路发送序列化消息（在netTcpBinding 的情况下为二进制序列化）。
另一端的服务器有一个运行时组件，它侦听这些消息并将它们从网络中取出、解包，然后调用服务实例以运行您想要的方法。
重要的部分是：它是一个基于消息的系统——除了合约（服务接口和以 XML 模式表示的数据结构）之外，您在运行时没有无连接两方之间。
这也意味着：服务器没有办法“返回”到客户端并找到一些东西或询问更多信息。所有服务必须处理的只是消息和您（或 WCF 运行时）可能已发送的任何潜在消息标头。就是这样。
另外：由于数据交换通过序列化消息进行，并且需要符合 XML 模式标准，因此您不能使用接口或泛型之类的东西 - 您只能传递类的具体实例。
总而言之 - WCF 确实在某些方面取代了 .NET 远程处理 - 但在某些方面，它是完全不同的野兽。这有利有弊，但您只需要了解这些差异并且不要试图与它们作斗争 - 您可以自行安排这些差异并从中受益，或者不要将 WCF 用于您的工作手。
【讨论】：
有一篇名为“Migrating .NET Remoting to WCF (and even ASMX!)”的旧文章不错，你应该看看。
我自己做了很多远程操作，在封闭的环境中我仍然认为它有它的位置。特别是当速度受到关注时。 （我不得不有点不同意远程处理是不可靠的。对于 LAN 通信我完全没有问题。）
我更喜欢 WCF 的一点是您必须创建代理对象，然后运行调用。您可以更轻松地看到您正在进行远程呼叫。远程处理在某种程度上隐藏了这个 imo。
需要注意的一点是，通过 WCF 设置事件比通过远程处理设置事件要多，但这是一个很小的代价。一旦您了解了 WCF 以及如何针对您的特定场景进行最佳配置，您将不会回头。它比远程更灵活，并且可以在更大的距离上使用，而远程不是很擅长（根据我的经验）。
请务必根据需要在 WCF 中选择一个传输通道，即 tcp、命名管道或soap。
【讨论】：