好吧，我已经在 StackOverflow 上问了几个关于 .NET Remoting 的问题，并且总是至少有一个人不得不插话，“.NET Remoting 已被弃用，请改用 WCF。”我知道它已被弃用，并且不能保证 future 会支持新版本的 .NET Framework。但是我们想要转移到 WCF 的其他一些充分理由是什么？我已经看到了 .NET Remoting 的一些主要是轻微的烦恼，但是，这不足以改变那些坚信“如果它没有坏，就不要修复它”的权力的想法。此时，态度会改变的唯一原因是如果 .NET Remoting 从 .NET Framework 的 future 版本中删除，那么谁知道那会持续多久呢？
是否有人知道为什么 WCF 比 .NET Remoting“更好”，或者为什么 Remoting 不如 WCF？每种技术的优缺点是什么？您可以使用 WCF 而不是 Remoting 执行其他操作吗？
我的意思是，如果我能说服他们让我们将我们的软件迁移到 WCF 只是为了允许在客户端设置可配置的 TcpChannel 超时，那就太好了(这似乎已经被打破了一段时间，没有无论我尝试了哪些步骤或故障排除)，当这种情况发生时，它会让我们的软件看起来一塌糊涂。
在此先感谢您帮助阐明这一点。
最佳答案
放弃远程处理的理由有很多；一些可能包括:
- 缺乏运输灵 active
- 版本控制的要求是巨大的痛苦
- 平台依赖(没有跨平台使用的合理机会)
- 没有机会从不断增长的移动市场中使用
- 缺乏 future 发展:无论您想添加什么功能 - 它都不会
但是，我不同意 WCF 是自动替代品； WCF 本身是一个非常通用的工具，但也可能非常复杂，并且有其自身的限制。我自己没用过，但我看到很多对Service Stack的赞美，基本上用户将其描述为“WCF 做得对”，即 WCF 的优点，没有痛点。但是，还有很多其他选择。不过，Service Stack 的想法有一个好处，那就是它的迭代速度非常快，如果它缺少您想要的东西，您可以更改它。
关于c# - 与继续使用 .NET Remoting 相比，将我们的应用程序迁移到 WCF 有什么好处？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12635360/