.NET Standard实现的gRPC客户端在.NET Framework调用失败但.NET Core 3.1正常

根本原因 #

.NET Framework 4.8 默认的 HttpClientHandler 对HTTP/2 over TLS的协商逻辑和.NET Core不同：要求服务端必须在TLS握手阶段通过ALPN扩展明确返回h2协议标识，才会启用HTTP/2通信。生产环境的服务E已经做了对应配置，本地开发的服务D缺少该配置，导致协商降级到HTTP/1.1，触发报错。

解决方案 #

1. 修改本地gRPC服务D的Kestrel配置，强制启用ALPN h2协商
   在服务D的Program.cs中调整Kestrel监听配置，明确指定HTTPS下的HTTP/2协议和ALPN支持：

ConfigureKestrel(serverOptions =>
{
    serverOptions.ListenAnyIP(你的服务端口, listenOpts =>
    {
        listenOpts.Protocols = HttpProtocols.Http2;
        listenOpts.UseHttps(httpsOpts =>
        {
            httpsOpts.HttpProtocols = HttpProtocols.Http2;
        });
    });
})

配置后重启服务，即可匹配生产环境的协商逻辑，.NET Framework客户端无需修改任何代码即可正常调用。

2. 修复本地自签证书的信任配置
   如果使用自签证书做本地测试，需要将证书安装到本地计算机的「受信任的根证书颁发机构」存储区，同时确保证书的使用者备用名称（SAN）包含你访问服务时用的域名/IP，.NET Framework对证书合法性的校验比.NET Core更严格，证书不合规也会导致TLS协商失败。

3. 客户端侧无感适配方案（无需修改上层业务代码）
   如果不想调整服务端配置，可以在.NET Standard的gRPC客户端类库中增加运行时判断，仅在.NET Framework环境下自动注入WinHttpHandler，上层调用方完全无感知，也不需要做接口抽象：

public static GrpcChannel CreateChannel(string serviceUrl)
{
    var options = new GrpcChannelOptions();
    #if NETFRAMEWORK
    options.HttpHandler = new WinHttpHandler();
    #endif
    return GrpcChannel.ForAddress(serviceUrl, options);
}

该条件编译仅在目标框架为.NET Framework时生效，.NET Core/.NET 5+环境仍使用默认Handler，不影响跨框架兼容性。

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