迁移至.NET 6时System.Runtime.Remoting.Lifetime的等效方案是什么

• 首先明确核心结论：System.Runtime.Remoting.Lifetime.LifetimeServices 所属的.NET Remoting技术栈，从.NET Core 1.0版本开始就被完全移除，.NET 5/6及后续版本均无内置对应实现，官方也没有发布过可还原该功能的NuGet包。社区第三方提供的Remoting兼容包大多仅实现了基础通信逻辑，没有完整还原租约生命周期管理能力，生产环境不推荐使用。
• 原LifetimeServices的核心作用是为Remoting体系下跨AppDomain、跨进程的MarshalByRefObject对象提供租约式生命周期管控：包括初始租约时长配置、续约触发、过期对象回收等能力，替代方案需要根据你的实际使用场景选择：

场景1：仅在同进程内使用LifetimeServices做对象生命周期管控 #

如果你的代码没有依赖Remoting做跨进程/跨AppDomain通信，只是借用LifetimeServices实现租约式的对象存活管理，不需要替换整个技术栈：

• 可以自行实现轻量租约管理逻辑：用ConcurrentDictionary存储每个对象的租约过期时间、关联回调，配合Timer做后台定时扫描，给需要续约的对象暴露Renew接口即可，整体逻辑和原LifetimeServices的行为完全对齐，实现成本很低。
• 如果被管理的是业务服务类对象，可以直接复用.NET 6内置依赖注入容器的生命周期能力：根据业务需要选择单例、作用域、瞬态三种生命周期即可，特殊的过期回收逻辑可以通过IHostedService实现后台清理，不需要重复造轮子。

场景2：依赖Remoting跨进程/跨节点通信，同时用LifetimeServices管理远程对象生命周期 #

这种场景需要整体替换Remoting技术栈，.NET 6官方推荐的替代RPC方案都自带成熟的对象生命周期管理能力：

• 跨网络跨节点通信优先选gRPC：这是.NET 6官方主推的跨平台RPC框架，原生支持服务实例生命周期配置，可灵活设置服务端对象是单例、每次请求新建、按连接存活，完全可以覆盖原LifetimeServices的远程对象管控需求。
• 同机器跨进程通信可以选内置IPC/命名管道：.NET 6内置System.IO.PipesAPI和封装好的进程间通信库，通信两端可以自行约定租约、续约规则，实现轻量的远程对象生命周期管控。

注意：不要尝试将.NET Framework下的System.Runtime.Remoting相关程序集直接拷贝到.NET 6项目中加载，Remoting依赖大量.NET Framework独有的底层AppDomain、运行时接口，在.NET 6下会直接抛出兼容性异常，完全无法正常运行。

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