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 封装”。
