.NET 5.0下System.Runtime.Remoting的同类替代方案咨询

针对仅内网使用、低迁移成本的需求，以下是适配性从高到低的可选方案：

方案1：CoreWCF（迁移成本最低，与.NET Remoting使用习惯最接近） #

CoreWCF是微软官方维护的WCF在.NET Core/.NET 5+平台的移植实现，完全适配内网TCP远程调用场景，和.NET Remoting的面向接口、代理调用的逻辑高度一致。

• 原有Remoting定义的服务接口、可序列化传输实体几乎可以100%复用，仅需要调整服务端注册、客户端代理创建的框架代码
• 支持TCP绑定，内网传输性能与原.NET Remoting相当，满足远程控制场景的低延迟需求
• 标记了[Serializable]或[DataContract]的原有业务传输类不需要做任何修改即可直接使用

方案2：gRPC for .NET（性能最优，适合后续扩展） #

如果可接受少量接口改造工作量，可以选择.NET 5原生支持的gRPC框架：

• 需要先通过.proto文件定义服务接口与数据结构，官方提供代码生成工具，可自动生成服务端骨架与客户端代理代码
• 基于HTTP/2传输、Protobuf二进制序列化，性能优于原.NET Remoting
• WPF客户端仅需安装Grpc.Net.Client NuGet包即可完成对接，服务端可直接在ASP.NET Core宿主中挂载gRPC服务

方案3：Orleans（适合分布式对象场景） #

如果原有.NET Remoting使用了远程对象激活、分布式状态保持的能力，可以选择Orleans框架：

• Grain对象的调用模式与.NET Remoting的远程激活对象逻辑高度相似，上层业务调用习惯几乎不需要调整
• 原生支持分布式扩展，可适配后续更复杂的内网多节点控制需求

选择建议 #

优先选择CoreWCF方案，可最大化复用原有业务代码，迁移改造工作量最小，完全匹配你当前内网远程控制的场景需求。如果后续有跨技术栈调用、性能升级的规划，再考虑切换到gRPC方案。

内容的提问来源于stack exchange，提问作者Jeff H