前提条件 - 远程服务器和客户端都已设置，客户端能够通过客户端激活的业务对象调用方法并在服务器端/从服务器端接收事件。
在保持服务器和客户端运行的情况下更改远程服务器的IP地址，客户端仍然可以执行上述任务。
这很棘手。
编辑： 设置频道时删除了 bindTo
【问题讨论】：
来吧，现在是 2010 年...已经让它成为 WCF 应用程序了。
要回答您的“性能”问题，请查看线程 Performance WCF vs .NET remoting
WCF与之前其他通信技术的全面对比HERE
通过使用 WCF，您将摆脱一些令人头疼和令人耳目一新的场景。这是一个安全的赌注，我向你保证，你不会后悔的。
引用 Saurabh Gupta（MS 的 WCF PM）：
在将使用 ASP.NET Web Services、WSE、.NET Enterprise Services 和 .NET Remoting 编写的分布式应用程序迁移到 WCF 时，性能至少可以与其他现有的 Microsoft 分布式通信技术相媲美。在大多数情况下，WCF 的性能明显优于其他现有技术。 WCF 的另一个重要特性是吞吐量性能本质上可以从单处理器扩展到四处理器。
总结结果，WCF 比 ASP.NET Web 服务快 25%—50%，比 .NET Remoting 快约 25%。与 .NET Enterprise Service 的比较取决于负载，因为在一种情况下 WCF 快了近 100%，但在另一种情况下慢了近 25%。对于 WSE 2.0/3.0 实现，将它们迁移到 WCF 显然会提供几乎 4 倍的最显着的性能提升。
【讨论】：
.NET Remoting 比 WCF 更快的唯一情况是在同一进程中的 appdomains 之间远程处理数据以及序列化 ADO.NET DataSet 对象时。
除此之外，WCF 几乎总是更快：A Performance Comparison of Windows Communication Foundation (WCF) with Existing Distributed Communication Technologies：
此外，当托管在 IIS 中时，WCF 服务会自动映射到网络连接的新 IP 地址。 .NET Remoting 则不能这样说。
虽然一些现有应用程序继续使用 .NET Remoting，但它已被弃用，您应该意识到您编写和部署的任何 .NET 代码在某些时候都需要被替换。最好现在就移植到 WCF，而不是稍后在遇到砖墙截止日期时进行。
【讨论】：