IceRPC 是轻量级现代 .NET RPC 库，无需 Slice、无对象适配器、不依赖 IceGrid；纯 C# 接口 + JSON/MessagePack 序列化即可端到端调用，与旧 Ice 技术路线完全不同。
IceRPC 不是传统意义上的“框架”，而是一个轻量、现代的 .NET RPC 通信库（2023 年起由 ZeroC 推出，用于替代旧 Ice 3.x 的 Ice 运行时），它不依赖 Slice 编译、不强制服务注册中心、不内置对象适配器或 IceGrid。你用 C# 写接口，直接用 System.Text.Json 或 MessagePack 序列化，就能跑通端到端调用。
所以，别被名字误导：IceRPC 和老版 Ice（即带 Slice、Adapter、IceBox、Registry 那套）是两条技术路线——前者是“极简 HTTP/2 + RPC 语义”，后者是“重型分布式对象中间件”。
Slice 文件在 IceRPC 中完全不需要
老 Ice 的 slice2cs 工具、Ice.Object、Proxy、Identity 这些概念，在 IceRPC 里统统不存在。你写的是纯 C# 接口，比如：
public interface IGreeter
{
Task<string> SayHelloAsync(string name);
}然后用 IceRpc.ClientConnection 直接调用，无需生成任何中间代码。Slice 在这里不是“入门门槛”，而是“完全无关项”。
为什么有人会混淆 IceRPC 和 Ice？
- 名字都带
Ice，ZeroC 官方文档初期没划清边界； - 旧版 Ice 的 C# 示例满屏都是
PrinterI、_PrinterDisp、slice2cs，新手一搜就撞上； -
IceRPC的 NuGet 包名是IceRpc，而老 Ice 的 C# 包是zeroc.ice（含大量 native 依赖）；
常见错误现象：
- 执行
slice2cs报错 “command not found” → 因为IceRPC不带任何 Slice 工具； - 引用
Ice命名空间后找不到Communicator或ObjectPrx→ 你在用 IceRPC，但查的是 Ice 3.7 文档； - 试图配置
IceGrid.Registry或写IceBox配置 → 这些组件 IceRPC 根本不加载。
C# 开发者该选 IceRPC 还是老 Ice？
- 选
IceRPC如果：你要快速验证跨进程/跨机器的 RPC 调用、用 ASP.NET Core Host、需要 gRPC 兼容性、不想碰 XML 配置和节点拓扑； - 选老
Ice（zeroc.ice）如果：你维护遗留系统、必须支持 C++/Java 客户端混部、需要自动故障转移 + IceGrid 服务发现 + 持久化对象激活。
性能与兼容性影响：
-
IceRPC默认走 HTTP/2，启动快、无 native 依赖、dotnet publish --self-contained false即可部署； - 老
Ice用自研二进制协议（Compact Format），吞吐略高，但需部署icebox.exe、icegridnode等进程，Windows/Linux/macOS 行为差异大。
真正容易被忽略的一点：IceRPC 的 IConnectionContext.Invoker 支持服务端主动回调客户端（所谓“打洞”），但前提是客户端也运行一个 ServerConnection 并暴露 endpoint——这不是默认行为，也不会在入门示例里体现，但却是它区别于 gRPC 的关键能力。没意识到这点，就容易把 IceRPC 当成“又一个 gRPC 封装”。
