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