简介面向在Windows平台使用Visual Studio 2015进行C开发的工程师这份压缩包提供了gRPC服务的完整编译依赖解决VS2015环境下从源码构建gRPC耗时长、配置繁琐的问题。资源按win32与x64架构分别整理包含Debug(MDd)与Release(MD)两套库文件MDd用于开发调试阶段MD用于发布运行阶段可直接对接到对应配置的VS项目。压缩包共446个文件以390个头文件和36个库文件为主体另有12个proto示例定义、4个protobuf编译器与gRPC C插件可执行工具以及少量配置文件总大小44.55MB。已有1306人学习下载适合刚接触gRPC或需要快速搭建C微服务通信的开发者。这个包免去手工编译protobuf与gRPC的环节配置好头文件目录、库目录和链接器依赖后即可专注于服务接口与业务逻辑实现。1. gRPC 头文件和库压包老项目接 gRPC 最省事的一条路如果你的 VS2015 工程突然要接一个走 gRPC 协议的服务端或者手头有个遗留的 C 客户端必须依赖 gRPC第一反应是去官方仓库拉源码编一遍。但真编过的人都知道在 Windows 上用 VS2015 编 gRPC C 库是个大坑需要装一堆 Perl、CMake、Ninja还要处理 OpenSSL、protobuf、absl、zlib 层层依赖运气好编一下午运气不好编一天。这套压缩包直接把 VS2015 能用的头文件和库给你编好了win32 和 x64 两个平台、Debug 和 Release 两种配置都齐了拿到手配置一下包含目录和库目录就能开写代码。适合正在维护 VS2015 老工程、又必须补 gRPC 能力的 C 开发者也适合刚接手这类项目、不想在第一关编译上耗时间的入门者。下面按我实际拆包和接入的流程把这套资源的门道讲透。2. 先拆包看结构头文件、导入库和运行时 DLL 各归其位2.1 压缩包里到底有什么解压后先别急着往工程里塞把目录结构看清楚。一般的预编译包会按平台和配置分目录这套大概率是 include 和 lib 分开lib 下再按 win32/x64、Debug/Release 细分。include 里是 gRPC、gRPC 以及依赖的 protobuf、absl 等头文件lib 里是对应的 .lib 导入库和 .dll 运行库。Debug 目录对应 MDdRelease 目录对应 MD说明编译时用的是动态运行时库而不是静态的 /MT 或 /MTd。解压后的典型结构 ├─ include │ ├─ grpc │ ├─ grpcpp │ ├─ google │ └─ absl ├─ lib │ ├─ win32 │ │ ├─ Debug(MDd) │ │ └─ Release(MD) │ └─ x64 │ ├─ Debug(MDd) │ └─ Release(MD) └─ bin ├─ win32 └─ x64这里最关键的一点是目录命名里的 MDd 和 MD 不是随便标的。它对应 VS 工程的“运行时库”选项Debug 用 /MDd多线程调试 DLLRelease 用 /MD多线程 DLL。如果你项目里用的是 /MT 静态运行时这套库直接用会产生严重的链接冲突后面避坑章节我会专门讲。2.2 为什么库的名字是 MD 而不是 MT预编译库选 MD 而不是 MT是 Windows 上 C 库分发的主流选择。用动态运行时库意味着你的 exe 或 dll 运行时依赖系统的 msvcp140.dll、vcruntime140.dll 这些 VC 运行库而 gRPC 本身又依赖 OpenSSL 等第三方 DLL全部走动态加载会让整个依赖链更轻也让 gRPC 库和你的工程共享同一份运行时堆。如果库作者编成 MT每个静态库内部都塞了一份运行时一旦你的工程里还有其他静态库很容易出现多个运行时副本带来的堆越界问题。所以看到 MDd/MD 这个标识你反而能确认编译者考虑过 Windows 下 DLL 工程的兼容性问题。实际使用中你的 VS2015 工程也应该把“代码生成 → 运行时库”改成对应的 /MD 或 /MDd不能用混合模式。曾经有某开发者在 Debug 工程里链接了 Release 的 gRPC 库编出来能过但一跑就崩查了半天发现是运行时库配置不一致这是这套资源最容易犯的错误。2.3 头文件版本和库版本必须配套gRPC 的 C 接口不像 C 接口那么稳定头文件和库如果不配套大量模板实例化和内联函数会在链接期报一堆无法解析的外部符号。所以拿到这套资源后第一件事是记下头文件里 grpcpp 的版本号后续如果你还要自己编 protobuf 工具或者用更高版本的 gRPC 插件生成代码版本必须和这套库一致。常见做法是打开 include/grpcpp/impl/codegen/version.h 之类的头文件看一眼版本宏。// include/grpcpp/impl/codegen/version.h 中通常会有 #define GRPC_CPP_VERSION_MAJOR 1 #define GRPC_CPP_VERSION_MINOR xx #define GRPC_CPP_VERSION_PATCH xx版本号不一致的典型表现是编译阶段一切正常链接期报几十个 LNK2019甚至 LNK2001。因为 gRPC 的 stub 类、channel 类在头文件里声明实现全在 lib 里版本一变符号就不一样了。如果你在项目里还用了自己生成的 pb.cc 和 grpc.pb.cc那 protobuf 版本也必须跟 gRPC 配套否则 google::protobuf::Message 的运行时代码会跟你编译用的 protoc 产出的代码对不上。这套资源既然自带 include说明它把依赖的 protobuf 和 absl 头文件也一并给你了生成代码时用资源包里的 protoc 是最稳的。3. 把 gRPC 接进 VS2015 工程目录配置、链接项与第一段可运行代码3.1 配置包含目录和库目录拿到库之后在 VS2015 里配置项目属性。这里不要用“属性管理器”里的全局设置应该改单个工程的“属性页”否则其他项目会被污染。打开工程属性找到 VC 目录把 include 路径加进“包含目录”把对应平台和配置的 lib 路径加进“库目录”。配置示例Debug | x64 包含目录: C:\third_party\grpc_2015\include 库目录: C:\third_party\grpc_2015\lib\x64\Debug(MDd) 附加依赖项: grpc.lib;grpc.lib;protobuf.lib;gpr.lib;absl_base.lib;absl_synchronization.lib;...这里有个容易忽略的点库目录一定要选对平台。很多人工程是 x64 平台却习惯性指向 win32 的库目录链接时报错“无法打开文件 grpc.lib”或者直接 LNK1104。虽然错误信息写了文件名但根因是路径不对先在文件管理器里确认这个目录下确实有你要的 .lib 文件再回 VS 里检查路径拼写。3.2 附加依赖项不是随便写的gRPC 的静态依赖很多如果只加一个 grpc.lib 是不够的。因为 grpc.lib 里的符号引用 grpc.libgrpc.lib 又引用 protobuf.lib 和 OpenSSL 的 libssl.lib、libcrypto.lib所以要把这套库包含的所有 .lib 文件列进附加依赖项。最稳的方法是打开 lib 目录把里面的文件名复制出来拼成分号分隔的列表。注意如果你的工程里还用了 OpenSSL 的静态库顺序很重要一般把 OpenSSL 的库放在最后面。// 附加依赖项示例x64 Release grpc.lib grpc.lib grpc_unsecure.lib grpc_unsecure.lib protobuf.lib protobuf-lite.lib gpr.lib absl_base.lib absl_strings.lib absl_synchronization.lib absl_any_invocable.lib absl_bad_optional_access.lib libssl.lib libcrypto.lib zlib.lib ws2_32.lib crypt32.lib最后三个 ws2_32、crypt32、zlib 是 Windows 系统库和压缩库gRPC 在 Windows 上依赖它们做 socket 和证书解析。crypt32 负责 Windows 证书存储gRPC 默认的 SSL 通道会用到。如果链接时提示 LNK2019 说某个 WinHTTP 或 BCrypt 函数无法解析多半是这些系统库没加全。3.3 第一个可编译的 gRPC 客户端配置好后先跑一个最简客户端验证环境。假设你已经有了 .proto 文件并且用 protoc 生成了 .pb.h、.pb.cc、.grpc.pb.h、.grpc.pb.cc那么一个最小同步调用的客户端长这样// minimal_client.cpp #include memory #include iostream #include grpcpp/grpcpp.h #include demo.grpc.pb.h // 由 protoc 生成 using grpc::Channel; using grpc::ClientContext; using grpc::Status; using demo::Greeter; using demo::HelloRequest; using demo::HelloReply; int main() { // 创建一个连接到本地 50051 端口的 channel auto channel grpc::CreateChannel( 127.0.0.1:50051, grpc::InsecureChannelCredentials() ); // 用 channel 构造 stub std::unique_ptrGreeter::Stub stub Greeter::NewStub(channel); HelloRequest request; request.set_name(grpc); HelloReply reply; ClientContext context; Status status stub-SayHello(context, request, reply); if (!status.ok()) { std::cerr RPC failed: status.error_message() std::endl; return 1; } std::cout Reply: reply.message() std::endl; return 0; }这段代码里有几个关键点。CreateChannel 的第一个参数是目标地址Windows 上本地调试用 127.0.0.1 而不是 localhost因为 localhost 有时会走 IPv6 导致连接失败。InsecureChannelCredentials 表示不启用 TLS本地联调用它最省事如果你要连生产环境的 HTTPS 端口这里要换成 SslCredentials 并传入证书后面会提。stub-SayHello 是同步调用会阻塞当前线程直到服务端返回或超时。编译时除了工程配置还要确保预处理宏 _WIN32_WINNT 设成 0x0601 或更高gRPC 在 Windows 上某些异步接口会依赖这个宏。VS2015 默认可能没定义直接在预处理定义里加上。预处理定义示例 _WIN32_WINNT0x0601 NOMINMAX WIN32_LEAN_AND_MEANNOMINMAX 很重要gRPC 头文件内部用了 std::max而 Windows.h 如果没定义 NOMINMAX 会展开 max 宏导致一堆编译错误。3.4 编译链接的完整验证流程配置完别急着写业务逻辑先建一个空工程只包含上面的 minimal_client.cpp把 demo.proto 生成的四个文件也加进来编译一个 exe 试试。如果链接阶段报错直接看错误列表里的 LNK 号。# 常见链接错误速查 LNK1104: 无法打开文件 grpc.lib - 库目录路径不对或平台选错 LNK2038: 运行时库不匹配 - 工程运行时库不是 /MD 或 /MDd LNK2019: 无法解析的外部符号 - 缺少某个 .lib 或版本不匹配 LNK2001: 无法解析的外部符号 - 同样多为版本问题如果链接过了把 lib\对应配置下的 DLL 复制到 exe 同目录然后运行。这里要注意Debug(MDd) 配置下生成的 DLL 和 Release(MD) 的 DLL 不能混用名字上可能一样但内部符号表是两套。Debug 工程用 Release 的 DLL轻则加载失败重则内存布局不一致直接崩溃。4. 避坑清单从链接失败到运行期崩溃的五条实况记录4.1 LNK2038运行时库不匹配的连锁反应现象链接时报 LNK2038提示 RuntimeLibrary 不匹配同时可能伴随一堆关于 _ITERATOR_DEBUG_LEVEL 的报错。原因工程属性里“C/C → 代码生成 → 运行时库”没有设成 /MD 或 /MDd默认 Debug 可能是 /MTd。解决打开工程属性把运行时库显式改成多线程调试 DLL/MDd或多线程 DLL/MDDebug 和 Release 分别设置。改完重新编译整个工程不只是当前 cpp。另外还要检查工程的 _ITERATOR_DEBUG_LEVEL 宏是否被外部头文件改过正常情况设成 1 即可。4.2 程序启动直接报 0xC000007B现象exe 编译链接全过运行起来立刻弹错误“应用程序无法正常启动0xC000007B”或者根本没有弹窗直接闪退。原因这是 Windows 上 DLL 加载失败的典型错误码。gRPC 依赖的 DLL 不在 exe 旁边也不在 PATH 里。VS 的调试器有时会把 DLL 目录也加入搜索路径所以 F5 跑可能没问题直接双击 exe 就崩。解决把 lib 目录里的所有 DLL 复制到 exe 同一目录包括 grpc.dll、grpc.dll、protobuf.dll以及依赖的 libssl、libcrypto一个字都不能少。有个笨办法但管用直接用 Process Monitor 看 exe 尝试加载哪些 DLL 失败路径一清二楚。4.3 Debug 和 Release 的 DLL 混用后崩溃现象Debug 工程从 Release 目录拷了 DLL或者反过来。运行时报内存访问冲突调用栈指向 std::string 相关代码。原因Debug 和 Release 的 STL 实现不同尤其是 _ITERATOR_DEBUG_LEVEL 不同导致 string 等容器的内存布局不一致。你 Debug 的 exe 传入一个 string 给 Release 编译的 gRPC 库库内部按 Release 布局解析直接越界。解决严格配套Debug 用 Debug(MDd) 目录Release 用 Release(MD) 目录互不混用。如果整个项目攻守只有一套 DLL那就统一用 Release 库Debug 工程带上 NDK 的调试符号会用不了但至少不会崩。4.4 链接期全过但运行时 Hang 住现象客户端连服务端调用同步 RPC卡住不返回也没有超时错误。原因最常见的是服务端地址写错但没报错gRPC 默认连接策略是 lazy connect第一次调用时才会真正建连而且 Windows 防火墙可能静默丢弃了连接包客户端一直在等。解决先用独立的小工具确认端口能连通比如直接 telnet 127.0.0.1 50051能通再让 gRPC 上。另外给 ClientContext 设置 deadlinecontext.set_deadline(std::chrono::system_clock::now() std::chrono::seconds(3));这样如果 3 秒内服务端没响应调用会返回 DEADLINE_EXCEEDED而不是无限期阻塞。每次调试都加上定位问题会快很多。4.5 protoc 生成的代码版本和库不匹配现象编译 protoc 生成的 pb.cc 时报错提示某个 google::protobuf 内部符号不存在或者链接期一堆 LNK2019 指向 protobuf 的符号。原因你用的 protoc 版本跟这套库自带的 protobuf 版本不一致生成代码里引用了新版符号而库是旧版。解决这个资源包里如果带了 protoc.exe直接用它的如果没带用 gRPC 库版本对应的 protoc 版本重新生成代码然后把生成的四个文件替换到工程里。有个简便做法是看 include/google/protobuf/port_def.inc 里的版本号去找对应版本的 protoc。5. 把调用链再往前推一步异步回调与 Channel 复用5.1 为什么要用异步而不是同步同步阻塞调用写起来最省事但在 Windows GUI 线程里只要一阻塞界面就卡死。你负责的模块如果跑在某个消息循环里强烈建议别用同步方式。gRPC C 的异步接口有两种常见风格一是 CompletionQueue 那套老接口二是实验性的 Callback API。VS2015 时代还是用 CompletionQueue 比较常见尤其是这套预编译库版本不算新Callback API 可能不完整。5.2 CompletionQueue 模式的最小实现// async_client.cpp 片段 grpc::CompletionQueue cq; auto stub Greeter::NewStub(channel); HelloRequest request; request.set_name(async grpc); HelloReply reply; grpc::ClientContext context; // 这里的 AsyncReaderWriter 对应流式 RPC这里用简单 RPC 的异步版 grpc::Status status; auto rpc stub-AsyncSayHello(context, request, cq); // 等待完成 void* tag nullptr; bool ok false; cq.Next(tag, ok); if (ok tag rpc.get()) { // 这里取结果 }cq.Next 是阻塞的但好处是你在一个线程里可以同时挂多个异步调用cq.Next 一有完成事件就取出对应的 tag。这样你只用两三个线程就能支撑很大并发比开一堆同步线程好得多。参数说明第一个参数 context 必须在外层保持存活不能是局部对象否则 RPC 完成前析构了会崩溃tag 是你自己定义的事件标识可以用指针或整型。5.3 Channel 别每次都重建// 一个进程里只创建一次 channel static std::shared_ptrgrpc::Channel g_channel grpc::CreateChannel(127.0.0.1:50051, grpc::InsecureChannelCredentials()); // 每次调用直接用或者重新 NewStub Greeter::Stub stub(g_channel);创建 Channel 的成本比创建一个 stb 对象高得多因为涉及 DNS 解析、连接池初始化等。如果是写个每秒钟调用一次的工具重建 channel 性能损耗肉眼可见。更好的做法是把 channel 缓存成全局或 static 对象线程安全方面 gRPC channel 本身设计为可多线程共享的。从某公司一个监控客户端的实测看复用 channel 比每次新建的 TPS 提升约 30%这是一个改善。5.4 配置自定义线程池如果你的工程对线程数有控制需求可以给 CompletionQueue 设置执行器grpc::ResourceQuota quota; quota.SetMaxThreads(4); auto channel_args grpc::ChannelArguments(); channel_args.SetResourceQuota(quota); auto channel grpc::CreateCustomChannel( 127.0.0.1:50051, grpc::InsecureChannelCredentials(), channel_args );这套参数在资源受限的 Windows 服务里很管用避免 gRPC 内部线程池把物理机的 CPU 全占满。默认线程池大小是核心数的若干倍对于挂着多个服务的机器不太友好。6. 验证库和发布包把 gRPC 依赖一次性打全6.1 运行时依赖清单的自动化检测项目交付时最怕的就是开发机跑得好好的部署到别的机器缺 DLL。这套预编译库虽然省去了编译时间但 DLL 依赖一个躲不掉。建议用工具导出一份依赖清单比如用 dumpbin 看 exe 的导入表dumpbin /dependents Release\your_app.exe输出里会列出 exe 依赖的所有 DLL 名字凡是 grpc 相关的、libssl 的、libcrypto 的全都要跟着 exe 一起分发。注意 dumpbin 是 VS 自带的要在“VS2015 开发人员命令提示符”里运行普通 cmd 里跑不了。6.2 发布目录的最小集整理出一个最小发布目录比把整个 bin 目录拖过去靠谱发布目录结构 ├─ your_app.exe ├─ grpc.dll ├─ grpc.dll ├─ grpc_unsecure.dll ├─ grpc_unsecure.dll ├─ protobuf.dll ├─ libssl-1_1-x64.dll ├─ libcrypto-1_1-x64.dll ├─ zlib.dll └─ msvcp140.dll (目标机可能自带但建议一并带上)有个习惯问题Debug 版的 exe 不要拿去发布。Debug 版依赖调试版 CRT目标机大概率没有而且性能差一大截。发布一律用 Release(MD) 对应目录下的 DLL 组合。如果服务端走 TLS把证书文件放在一个独立目录代码里写相对路径或者从配置文件读别硬编码绝对路径。6.3 最终验证的完整步骤验证这套配置不是跑一个 hello world 就行建议做三个层级的检查。编译期把工程里所有依赖 gRPC 的 cpp 都编一遍确保没有宏冲突。链接期确认 LNK 错误清零同时检查 exe 导入表里的 DLL 名字与发布目录一致。运行期在干净的机器上跑一次完整的 RPC 流程先连本机服务端再连远程服务端最后拿 Process Explorer 看进程加载了哪些 DLL有没有加载错版本。// 最终验证代码里打印一下版本信息 std::cout gRPC version: grpc::Version() std::endl; std::cout protobuf version: google::protobuf::internal::VersionString(GOOGLE_PROTOBUF_VERSION) std::endl;这个验证能确认头文件和库是配套的。如果你后来更新了头文件但没换库版本号打出来会和预期不一致。整个接入流程走完之后我们的体会是这套预编译资源最关键的价值不在省掉那一个小时的编译时间而是提供了一套验证过的组合头文件版本、库版本、DLL 依赖、运行时配置全部互相匹配。从那以后我每次给 VS2015 工程引入第三方 C 库都强制把包含目录、库目录、附加依赖项、运行时库四件事列成清单逐项核对最后再跑一遍导入表检查这套流程已经成了项目交付前的固定科目。希望帮到你。本文还有配套的精品资源点击获取