简介这份资源面向在 Windows 平台使用 C 进行微服务与分布式系统开发的工程师提供基于 Visual Studio 2015 编译的 gRPC 完整开发环境解决从源码编译到工程配置的繁琐问题。压缩包共 884 个文件约 71.97MB以 430 个 h 头文件、306 个 cc 源文件、64 个 proto 接口定义文件为主并附带 18 个 lib 静态库、8 个 dll 动态库及 26 个 exe 可执行文件同时包含 vcxproj、sln、props 等 VS 工程配置方便直接集成。资源内置 Debug 与 Release 两套编译产物并自带一个可运行的 helloworld 测试项目通过 Greeter 服务的 SayHello 方法演示服务定义、Stub 生成与调用流程便于快速验证环境。已有 1758 人学习下载适合希望跳过编译踩坑、直接上手 gRPC 服务端与客户端开发的 C 开发者参考使用。1. 从一台老开发机说起为什么 grpc windows vs2015 这套组合至今还有人踩上周帮一个做工业上位机的朋友收拾一台 Windows 7 开发机机器上锁死了 Visual Studio 2015项目里要接一个跨进程的 RPC 通信层选来选去还是落到 gRPC C 上。结果从 clone 到编译通过整整折腾了一个下午——不是 gRPC 本身难而是 grpc windows vs2015 这套组合的坑几乎全集中在「版本对不对得上」和「依赖从哪来」这两件事上。VS2015 的 MSVC 工具集是 v140C11 支持是够的但 gRPC 从某个版本之后就开始要求 C14 甚至 C17第三方依赖也跟着水涨船高选错一个 tag后面就是无穷无尽的编译错误。这篇笔记就是把这套环境从零装到能跑通 Hello World 的完整过程记下来包括版本怎么挑、依赖怎么拉、CMake 参数怎么配、装崩了怎么退回去。如果你手上也是一台被 VS2015 绑住、又必须上 grpc c windows 的机器照着走一遍能省掉大半天。2. 版本选型与依赖盘点VS2015 能吃到哪个 gRPC 版本2.1 先确认工具集和 C 标准这条硬线VS2015 对应的是 MSVC 19.00工具集 v140。它完整支持 C11对 C14 是部分支持C17 基本没有。gRPC C 的版本演进里v1.30 之前对 C11 还算友好越往后越依赖 C14/17 的语法和标准库设施。所以在这台机器上我一般会把 gRPC 锁在 v1.28.x 到 v1.33.x 这个区间再高就容易在编译 abseil 或者 protobuf 的时候炸出一堆constexpr和std::string_view相关的错误。这不是玄学是工具集能力决定的。先确认环境打开 VS2015 的开发者命令提示符跑一下cl输出里会带版本号形如19.00.xxxxx。只要主版本是 19.00就说明是 v140 工具集。如果机器上还装了别的 VS 版本务必用 VS2015 自带的那个命令提示符别用系统的 cmd否则 cl 可能指向别的工具集后面 CMake 生成的工程会用错编译器。2.2 依赖清单gRPC 不是一个人能装完的gRPC C 在 Windows 上编译绕不开这几个东西依赖作用VS2015 下的注意点CMake生成 VS 工程用 3.15 以上但别用 3.20 里默认的新行为Git拉源码和子模块必须带 submodule别下 zip 包NASM编译 OpenSSL 汇编装完要进 PATH否则 OpenSSL 编不过PerlOpenSSL 构建脚本Strawberry Perl 即可Go部分工具链可选但 boringssl 某些脚本会用到Ninja可选加速用 VS 生成器时可不装这里最容易翻车的是 NASM 和 Perl。很多人 clone 完直接 CMake结果卡在 OpenSSL 或者 boringssl 的汇编阶段报错信息还特别隐晦。我的习惯是先把 NASM、Perl、CMake、Git 全部装好并确认在 PATH 里再动 gRPC 的源码。2.3 拉源码submodule 一个都不能少gRPC 的仓库带了一堆第三方子模块直接下 zip 是拿不到这些的。正确姿势是git clone --recurse-submodules -b v1.33.2 https://github.com/grpc/grpc.git cd grpc git submodule update --init --recursive--recurse-submodules保证 clone 的时候就把子模块拉下来后面那条submodule update是双保险防止某些子模块没跟上。版本号v1.33.2是我在 VS2015 上验证过能编过的 tag再往前的 v1.28.x 也可以但 v1.33.x 的 API 更稳一些。如果你拉的是 master那基本可以放弃 VS2015 了master 早就要求 C17。拉完之后检查一下third_party目录里面应该有abseil-cpp、boringssl、protobuf、zlib等一堆目录每个目录里都得有实际文件空的就说明 submodule 没拉全得重新git submodule update --init --recursive。3. 编译安装CMake 参数怎么配才不炸3.1 生成 VS2015 工程生成器名字别写错CMake 生成工程这一步生成器的名字必须精确。VS2015 对应的是Visual Studio 14 2015 Win64注意是 14 不是 1515 是 VS2017。写错了 CMake 会直接报找不到生成器。mkdir build cd build cmake .. -G Visual Studio 14 2015 Win64 ^ -DCMAKE_BUILD_TYPERelease ^ -DgRPC_BUILD_TESTSOFF ^ -DgRPC_BUILD_CSHARP_EXTOFF ^ -DgRPC_INSTALLON ^ -DCMAKE_INSTALL_PREFIXC:/grpc-install逐条说下参数。-G指定生成器必须和本机 VS 版本严格对应。CMAKE_BUILD_TYPE在 VS 生成器下其实不直接生效因为 VS 是多配置生成器真正决定 Release/Debug 的是后面 build 时的--config但写上没坏处。gRPC_BUILD_TESTSOFF很关键gRPC 自带的测试用例编译量巨大而且很多测试在 VS2015 下编不过关掉能省一半时间。gRPC_BUILD_CSHARP_EXTOFF关掉 C# 扩展用不上就别编。gRPC_INSTALLON和CMAKE_INSTALL_PREFIX是为了后面能 install 到一个固定目录方便项目引用。如果 CMake 报错说找不到 ZLIB 或者 OpenSSL说明它想用系统库但没找到。gRPC 默认会自己编 boringssl 和 zlib一般不用管但如果你的环境里装了别的 OpenSSL 并且被 CMake 优先找到了就可能出问题。稳妥做法是加-DgRPC_SSL_PROVIDERpackage或者干脆让它用自带的 boringssl不加额外参数就是默认自带。3.2 编译Release 配置 并行度控制工程生成之后用 CMake 的 build 命令直接编cmake --build . --config Release --target install -- /m:4--config Release指定编 Release 版VS 生成器下必须显式指定。--target install表示编完直接安装到前面设的CMAKE_INSTALL_PREFIX。最后的/m:4是传给 MSBuild 的并行编译参数4 是并行项目数。这个数别开太大gRPC 编译吃内存开 8 或者 16 很容易把机器内存打满然后卡死我一般按物理核数的一半来设。编译过程大概会持续 20 到 40 分钟取决于机器性能。中途如果报错最常见的是两类一类是abseil里的 C14 语法错误说明 gRPC 版本还是选高了另一类是boringssl的汇编错误说明 NASM 没装好或者没进 PATH。看到这两类错误先别急着改代码回头检查版本和依赖。3.3 安装产物编完之后装到哪了install目标跑完C:/grpc-install下会出现几个目录C:/grpc-install/ bin/ # grpc_cpp_plugin.exe 等工具 include/ # grpc、grpc、google/protobuf 头文件 lib/ # grpc.lib、grpc.lib、libprotobuf.lib 等 cmake/ # gRPCConfig.cmake供 find_package 用bin目录里的grpc_cpp_plugin.exe是后面生成 C 代码要用的插件必须能找到。lib目录里的库文件分 Debug 和 ReleaseRelease 版不带后缀Debug 版带d后缀链接的时候别搞混。cmake目录里的配置文件是给find_package(gRPC CONFIG)用的后面在项目里引用会很方便。4. 项目集成从 proto 到可执行文件4.1 写一个最小 proto 并生成代码先建一个测试目录写个最简单的 protosyntax proto3; package demo; service Greeter { rpc SayHello (HelloRequest) returns (HelloReply) {} } message HelloRequest { string name 1; } message HelloReply { string message 1; }存成greeter.proto。然后用前面装好的工具生成 C 代码C:/grpc-install/bin/protoc.exe ^ --grpc_out. ^ --cpp_out. ^ --pluginprotoc-gen-grpcC:/grpc-install/bin/grpc_cpp_plugin.exe ^ -I . ^ greeter.proto--grpc_out和--cpp_out都指定输出到当前目录。--plugin告诉 protoc 用哪个插件生成 gRPC 服务代码路径必须指到grpc_cpp_plugin.exe。-I .是 proto 的搜索路径。跑完会生成greeter.pb.cc、greeter.pb.h、greeter.grpc.pb.cc、greeter.grpc.pb.h四个文件前两个是消息类后两个是服务桩类。4.2 写服务端和客户端服务端最小实现#include grpcpp/grpcpp.h #include greeter.grpc.pb.h class GreeterServiceImpl final : public demo::Greeter::Service { grpc::Status SayHello(grpc::ServerContext* context, const demo::HelloRequest* request, demo::HelloReply* reply) override { std::string prefix(Hello ); reply-set_message(prefix request-name()); return grpc::Status::OK; } }; int main() { std::string address(0.0.0.0:50051); GreeterServiceImpl service; grpc::ServerBuilder builder; builder.AddListeningPort(address, grpc::InsecureServerCredentials()); builder.RegisterService(service); std::unique_ptrgrpc::Server server(builder.BuildAndStart()); server-Wait(); return 0; }客户端最小实现#include grpcpp/grpcpp.h #include greeter.grpc.pb.h int main() { auto channel grpc::CreateChannel(localhost:50051, grpc::InsecureChannelCredentials()); auto stub demo::Greeter::NewStub(channel); demo::HelloRequest request; request.set_name(VS2015); demo::HelloReply reply; grpc::ClientContext context; grpc::Status status stub-SayHello(context, request, reply); if (status.ok()) { std::cout reply.message() std::endl; } return 0; }这两个文件里grpcpp/grpcpp.h是 gRPC C 的总头文件InsecureServerCredentials和InsecureChannelCredentials表示不加密本地测试够用。ServerBuilder负责组装服务BuildAndStart之后调Wait阻塞住。客户端用CreateChannel建通道NewStub拿桩对象然后像调本地函数一样调远程方法。4.3 CMake 集成find_package 的写法在自己的项目里用find_package引用前面装好的 gRPCcmake_minimum_required(VERSION 3.15) project(demo) set(CMAKE_CXX_STANDARD 11) set(CMAKE_CXX_STANDARD_REQUIRED ON) find_package(gRPC CONFIG REQUIRED) find_package(Protobuf CONFIG REQUIRED) add_executable(server server.cpp greeter.pb.cc greeter.grpc.pb.cc) target_link_libraries(server PRIVATE gRPC::grpc gRPC::grpc_reflection) add_executable(client client.cpp greeter.pb.cc greeter.grpc.pb.cc) target_link_libraries(client PRIVATE gRPC::grpc)CMAKE_CXX_STANDARD 11是因为 VS2015 只稳到 C11写 14 或 17 可能编不过。find_package(gRPC CONFIG REQUIRED)会去找前面 install 出来的gRPCConfig.cmake所以配置的时候要加-DCMAKE_PREFIX_PATHC:/grpc-install。gRPC::grpc是 gRPC 导出的目标名链接它会自动带上依赖的 protobuf 和底层库。grpc_reflection是反射库服务端调试用得上不需要可以去掉。配置和编译cmake .. -G Visual Studio 14 2015 Win64 ^ -DCMAKE_PREFIX_PATHC:/grpc-install cmake --build . --config Release跑起来先起 server再起 clientclient 那边应该打印出Hello VS2015。到这一步整套 grpc c windows 环境就算通了。5. 避坑与排查VS2015 下最容易翻车的五个点5.1 现象CMake 报找不到生成器原因生成器名字写错或者本机没装对应版本的 VS。VS2015 的生成器名是Visual Studio 14 2015不是 15。如果装的是 64 位工具集还要加Win64。解决先用cmake --help看本机支持的生成器列表找到带2015的那一行原样抄过来。如果列表里没有 2015说明 VS2015 的 C 组件没装全回安装器里补上。5.2 现象编译 abseil 时报一堆 C14 语法错误原因gRPC 版本选高了高版本的 abseil 用了 VS2015 不支持的 C14 特性。解决退到 v1.33.x 或更低。如果已经拉了高版本git checkout v1.33.2然后重新git submodule update --init --recursive再清空 build 目录重新 CMake。别想着改 abseil 源码去兼容改不完的。5.3 现象boringssl 编译报 NASM 相关错误原因NASM 没装或者装了但没进 PATHCMake 找不到。解决装 NASM 后确认nasm -v能在命令行里跑通。如果 PATH 里有了还是报错检查是不是 32 位和 64 位版本混了64 位工具集要用 64 位 NASM。实在不行CMake 加-DgRPC_SSL_PROVIDERpackage用系统 OpenSSL 绕过去但系统 OpenSSL 的版本也得对得上。5.4 现象链接时报LNK2038或RuntimeLibrary不匹配原因Debug 和 Release 的库混用了或者运行库选项/MT 和 /MD不一致。解决确认项目里链接的 gRPC 库和当前编译配置一致Release 配 ReleaseDebug 配 Debug。运行库选项上gRPC 默认用 /MD自己的项目也保持一致别改成 /MT。5.5 现象运行时报DLL load failed原因grpc.dll、libprotobuf.dll这些动态库不在可执行文件的搜索路径里。解决把C:/grpc-install/bin加到系统 PATH或者把需要的 DLL 拷到 exe 同目录。用dumpbin /dependents server.exe可以看 exe 依赖哪些 DLL缺哪个补哪个。6. 装完怎么验证三步确认这套环境真的通了装完不算完得有一套能重复跑的验证流程不然下次换台机器又得从头猜。我一般按三步走每步都有明确的通过标准。第一步验证工具链本身。在命令行里跑C:/grpc-install/bin/protoc.exe --version C:/grpc-install/bin/grpc_cpp_plugin.exe --versionprotoc会打印 libprotoc 的版本号grpc_cpp_plugin一般没有--version参数直接跑会报用法错误但只要能报出用法而不是「不是内部或外部命令」就说明插件本身是可执行的。这一步过了说明安装产物是完整的。第二步验证 proto 生成链路。拿前面那个greeter.proto重新生成一遍代码然后检查四个输出文件是否都非空dir greeter.pb.cc greeter.pb.h greeter.grpc.pb.cc greeter.grpc.pb.h四个文件大小都不为 0且greeter.grpc.pb.h里能搜到class Greeter和SayHello说明插件工作正常。这一步是最容易被忽略的很多人装完 gRPC 就直接写业务代码结果 proto 生成失败后面全是连锁错误。第三步端到端跑通。先起 server再起 clientclient 输出Hello VS2015就算全通。为了确认不是偶然我会把 server 停掉再跑一次 client这时候 client 应该报连接失败而不是崩溃说明错误处理路径也是通的。验证项通过标准失败时先查protoc 版本打印 libprotoc 版本号PATH 和安装目录插件可执行报用法而非找不到命令bin 目录是否在 PATHproto 生成四个文件非空且含服务类插件路径和 proto 语法端到端client 打印 Hello VS2015端口占用和 DLL 依赖断连处理client 报错不崩溃错误处理代码这套流程我每次在新机器上装完都会走一遍前后不到五分钟但能挡掉后面百分之八十的「明明装好了却跑不起来」。从那以后我每次配 grpc windows vs2015 环境都强制先跑完这三步再动业务代码省下来的排查时间远比这五分钟多。希望帮到你。本文还有配套的精品资源点击获取
简介这份资源面向在 Windows 平台使用 C 进行微服务与分布式系统开发的工程师提供基于 Visual Studio 2015 编译的 gRPC 完整开发环境解决从源码编译到工程配置的繁琐问题。压缩包共 884 个文件约 71.97MB以 430 个 h 头文件、306 个 cc 源文件、64 个 proto 接口定义文件为主并附带 18 个 lib 静态库、8 个 dll 动态库及 26 个 exe 可执行文件同时包含 vcxproj、sln、props 等 VS 工程配置方便直接集成。资源内置 Debug 与 Release 两套编译产物并自带一个可运行的 helloworld 测试项目通过 Greeter 服务的 SayHello 方法演示服务定义、Stub 生成与调用流程便于快速验证环境。已有 1758 人学习下载适合希望跳过编译踩坑、直接上手 gRPC 服务端与客户端开发的 C 开发者参考使用。1. 从一台老开发机说起为什么 grpc windows vs2015 这套组合至今还有人踩上周帮一个做工业上位机的朋友收拾一台 Windows 7 开发机机器上锁死了 Visual Studio 2015项目里要接一个跨进程的 RPC 通信层选来选去还是落到 gRPC C 上。结果从 clone 到编译通过整整折腾了一个下午——不是 gRPC 本身难而是 grpc windows vs2015 这套组合的坑几乎全集中在「版本对不对得上」和「依赖从哪来」这两件事上。VS2015 的 MSVC 工具集是 v140C11 支持是够的但 gRPC 从某个版本之后就开始要求 C14 甚至 C17第三方依赖也跟着水涨船高选错一个 tag后面就是无穷无尽的编译错误。这篇笔记就是把这套环境从零装到能跑通 Hello World 的完整过程记下来包括版本怎么挑、依赖怎么拉、CMake 参数怎么配、装崩了怎么退回去。如果你手上也是一台被 VS2015 绑住、又必须上 grpc c windows 的机器照着走一遍能省掉大半天。2. 版本选型与依赖盘点VS2015 能吃到哪个 gRPC 版本2.1 先确认工具集和 C 标准这条硬线VS2015 对应的是 MSVC 19.00工具集 v140。它完整支持 C11对 C14 是部分支持C17 基本没有。gRPC C 的版本演进里v1.30 之前对 C11 还算友好越往后越依赖 C14/17 的语法和标准库设施。所以在这台机器上我一般会把 gRPC 锁在 v1.28.x 到 v1.33.x 这个区间再高就容易在编译 abseil 或者 protobuf 的时候炸出一堆constexpr和std::string_view相关的错误。这不是玄学是工具集能力决定的。先确认环境打开 VS2015 的开发者命令提示符跑一下cl输出里会带版本号形如19.00.xxxxx。只要主版本是 19.00就说明是 v140 工具集。如果机器上还装了别的 VS 版本务必用 VS2015 自带的那个命令提示符别用系统的 cmd否则 cl 可能指向别的工具集后面 CMake 生成的工程会用错编译器。2.2 依赖清单gRPC 不是一个人能装完的gRPC C 在 Windows 上编译绕不开这几个东西依赖作用VS2015 下的注意点CMake生成 VS 工程用 3.15 以上但别用 3.20 里默认的新行为Git拉源码和子模块必须带 submodule别下 zip 包NASM编译 OpenSSL 汇编装完要进 PATH否则 OpenSSL 编不过PerlOpenSSL 构建脚本Strawberry Perl 即可Go部分工具链可选但 boringssl 某些脚本会用到Ninja可选加速用 VS 生成器时可不装这里最容易翻车的是 NASM 和 Perl。很多人 clone 完直接 CMake结果卡在 OpenSSL 或者 boringssl 的汇编阶段报错信息还特别隐晦。我的习惯是先把 NASM、Perl、CMake、Git 全部装好并确认在 PATH 里再动 gRPC 的源码。2.3 拉源码submodule 一个都不能少gRPC 的仓库带了一堆第三方子模块直接下 zip 是拿不到这些的。正确姿势是git clone --recurse-submodules -b v1.33.2 https://github.com/grpc/grpc.git cd grpc git submodule update --init --recursive--recurse-submodules保证 clone 的时候就把子模块拉下来后面那条submodule update是双保险防止某些子模块没跟上。版本号v1.33.2是我在 VS2015 上验证过能编过的 tag再往前的 v1.28.x 也可以但 v1.33.x 的 API 更稳一些。如果你拉的是 master那基本可以放弃 VS2015 了master 早就要求 C17。拉完之后检查一下third_party目录里面应该有abseil-cpp、boringssl、protobuf、zlib等一堆目录每个目录里都得有实际文件空的就说明 submodule 没拉全得重新git submodule update --init --recursive。3. 编译安装CMake 参数怎么配才不炸3.1 生成 VS2015 工程生成器名字别写错CMake 生成工程这一步生成器的名字必须精确。VS2015 对应的是Visual Studio 14 2015 Win64注意是 14 不是 1515 是 VS2017。写错了 CMake 会直接报找不到生成器。mkdir build cd build cmake .. -G Visual Studio 14 2015 Win64 ^ -DCMAKE_BUILD_TYPERelease ^ -DgRPC_BUILD_TESTSOFF ^ -DgRPC_BUILD_CSHARP_EXTOFF ^ -DgRPC_INSTALLON ^ -DCMAKE_INSTALL_PREFIXC:/grpc-install逐条说下参数。-G指定生成器必须和本机 VS 版本严格对应。CMAKE_BUILD_TYPE在 VS 生成器下其实不直接生效因为 VS 是多配置生成器真正决定 Release/Debug 的是后面 build 时的--config但写上没坏处。gRPC_BUILD_TESTSOFF很关键gRPC 自带的测试用例编译量巨大而且很多测试在 VS2015 下编不过关掉能省一半时间。gRPC_BUILD_CSHARP_EXTOFF关掉 C# 扩展用不上就别编。gRPC_INSTALLON和CMAKE_INSTALL_PREFIX是为了后面能 install 到一个固定目录方便项目引用。如果 CMake 报错说找不到 ZLIB 或者 OpenSSL说明它想用系统库但没找到。gRPC 默认会自己编 boringssl 和 zlib一般不用管但如果你的环境里装了别的 OpenSSL 并且被 CMake 优先找到了就可能出问题。稳妥做法是加-DgRPC_SSL_PROVIDERpackage或者干脆让它用自带的 boringssl不加额外参数就是默认自带。3.2 编译Release 配置 并行度控制工程生成之后用 CMake 的 build 命令直接编cmake --build . --config Release --target install -- /m:4--config Release指定编 Release 版VS 生成器下必须显式指定。--target install表示编完直接安装到前面设的CMAKE_INSTALL_PREFIX。最后的/m:4是传给 MSBuild 的并行编译参数4 是并行项目数。这个数别开太大gRPC 编译吃内存开 8 或者 16 很容易把机器内存打满然后卡死我一般按物理核数的一半来设。编译过程大概会持续 20 到 40 分钟取决于机器性能。中途如果报错最常见的是两类一类是abseil里的 C14 语法错误说明 gRPC 版本还是选高了另一类是boringssl的汇编错误说明 NASM 没装好或者没进 PATH。看到这两类错误先别急着改代码回头检查版本和依赖。3.3 安装产物编完之后装到哪了install目标跑完C:/grpc-install下会出现几个目录C:/grpc-install/ bin/ # grpc_cpp_plugin.exe 等工具 include/ # grpc、grpc、google/protobuf 头文件 lib/ # grpc.lib、grpc.lib、libprotobuf.lib 等 cmake/ # gRPCConfig.cmake供 find_package 用bin目录里的grpc_cpp_plugin.exe是后面生成 C 代码要用的插件必须能找到。lib目录里的库文件分 Debug 和 ReleaseRelease 版不带后缀Debug 版带d后缀链接的时候别搞混。cmake目录里的配置文件是给find_package(gRPC CONFIG)用的后面在项目里引用会很方便。4. 项目集成从 proto 到可执行文件4.1 写一个最小 proto 并生成代码先建一个测试目录写个最简单的 protosyntax proto3; package demo; service Greeter { rpc SayHello (HelloRequest) returns (HelloReply) {} } message HelloRequest { string name 1; } message HelloReply { string message 1; }存成greeter.proto。然后用前面装好的工具生成 C 代码C:/grpc-install/bin/protoc.exe ^ --grpc_out. ^ --cpp_out. ^ --pluginprotoc-gen-grpcC:/grpc-install/bin/grpc_cpp_plugin.exe ^ -I . ^ greeter.proto--grpc_out和--cpp_out都指定输出到当前目录。--plugin告诉 protoc 用哪个插件生成 gRPC 服务代码路径必须指到grpc_cpp_plugin.exe。-I .是 proto 的搜索路径。跑完会生成greeter.pb.cc、greeter.pb.h、greeter.grpc.pb.cc、greeter.grpc.pb.h四个文件前两个是消息类后两个是服务桩类。4.2 写服务端和客户端服务端最小实现#include grpcpp/grpcpp.h #include greeter.grpc.pb.h class GreeterServiceImpl final : public demo::Greeter::Service { grpc::Status SayHello(grpc::ServerContext* context, const demo::HelloRequest* request, demo::HelloReply* reply) override { std::string prefix(Hello ); reply-set_message(prefix request-name()); return grpc::Status::OK; } }; int main() { std::string address(0.0.0.0:50051); GreeterServiceImpl service; grpc::ServerBuilder builder; builder.AddListeningPort(address, grpc::InsecureServerCredentials()); builder.RegisterService(service); std::unique_ptrgrpc::Server server(builder.BuildAndStart()); server-Wait(); return 0; }客户端最小实现#include grpcpp/grpcpp.h #include greeter.grpc.pb.h int main() { auto channel grpc::CreateChannel(localhost:50051, grpc::InsecureChannelCredentials()); auto stub demo::Greeter::NewStub(channel); demo::HelloRequest request; request.set_name(VS2015); demo::HelloReply reply; grpc::ClientContext context; grpc::Status status stub-SayHello(context, request, reply); if (status.ok()) { std::cout reply.message() std::endl; } return 0; }这两个文件里grpcpp/grpcpp.h是 gRPC C 的总头文件InsecureServerCredentials和InsecureChannelCredentials表示不加密本地测试够用。ServerBuilder负责组装服务BuildAndStart之后调Wait阻塞住。客户端用CreateChannel建通道NewStub拿桩对象然后像调本地函数一样调远程方法。4.3 CMake 集成find_package 的写法在自己的项目里用find_package引用前面装好的 gRPCcmake_minimum_required(VERSION 3.15) project(demo) set(CMAKE_CXX_STANDARD 11) set(CMAKE_CXX_STANDARD_REQUIRED ON) find_package(gRPC CONFIG REQUIRED) find_package(Protobuf CONFIG REQUIRED) add_executable(server server.cpp greeter.pb.cc greeter.grpc.pb.cc) target_link_libraries(server PRIVATE gRPC::grpc gRPC::grpc_reflection) add_executable(client client.cpp greeter.pb.cc greeter.grpc.pb.cc) target_link_libraries(client PRIVATE gRPC::grpc)CMAKE_CXX_STANDARD 11是因为 VS2015 只稳到 C11写 14 或 17 可能编不过。find_package(gRPC CONFIG REQUIRED)会去找前面 install 出来的gRPCConfig.cmake所以配置的时候要加-DCMAKE_PREFIX_PATHC:/grpc-install。gRPC::grpc是 gRPC 导出的目标名链接它会自动带上依赖的 protobuf 和底层库。grpc_reflection是反射库服务端调试用得上不需要可以去掉。配置和编译cmake .. -G Visual Studio 14 2015 Win64 ^ -DCMAKE_PREFIX_PATHC:/grpc-install cmake --build . --config Release跑起来先起 server再起 clientclient 那边应该打印出Hello VS2015。到这一步整套 grpc c windows 环境就算通了。5. 避坑与排查VS2015 下最容易翻车的五个点5.1 现象CMake 报找不到生成器原因生成器名字写错或者本机没装对应版本的 VS。VS2015 的生成器名是Visual Studio 14 2015不是 15。如果装的是 64 位工具集还要加Win64。解决先用cmake --help看本机支持的生成器列表找到带2015的那一行原样抄过来。如果列表里没有 2015说明 VS2015 的 C 组件没装全回安装器里补上。5.2 现象编译 abseil 时报一堆 C14 语法错误原因gRPC 版本选高了高版本的 abseil 用了 VS2015 不支持的 C14 特性。解决退到 v1.33.x 或更低。如果已经拉了高版本git checkout v1.33.2然后重新git submodule update --init --recursive再清空 build 目录重新 CMake。别想着改 abseil 源码去兼容改不完的。5.3 现象boringssl 编译报 NASM 相关错误原因NASM 没装或者装了但没进 PATHCMake 找不到。解决装 NASM 后确认nasm -v能在命令行里跑通。如果 PATH 里有了还是报错检查是不是 32 位和 64 位版本混了64 位工具集要用 64 位 NASM。实在不行CMake 加-DgRPC_SSL_PROVIDERpackage用系统 OpenSSL 绕过去但系统 OpenSSL 的版本也得对得上。5.4 现象链接时报LNK2038或RuntimeLibrary不匹配原因Debug 和 Release 的库混用了或者运行库选项/MT 和 /MD不一致。解决确认项目里链接的 gRPC 库和当前编译配置一致Release 配 ReleaseDebug 配 Debug。运行库选项上gRPC 默认用 /MD自己的项目也保持一致别改成 /MT。5.5 现象运行时报DLL load failed原因grpc.dll、libprotobuf.dll这些动态库不在可执行文件的搜索路径里。解决把C:/grpc-install/bin加到系统 PATH或者把需要的 DLL 拷到 exe 同目录。用dumpbin /dependents server.exe可以看 exe 依赖哪些 DLL缺哪个补哪个。6. 装完怎么验证三步确认这套环境真的通了装完不算完得有一套能重复跑的验证流程不然下次换台机器又得从头猜。我一般按三步走每步都有明确的通过标准。第一步验证工具链本身。在命令行里跑C:/grpc-install/bin/protoc.exe --version C:/grpc-install/bin/grpc_cpp_plugin.exe --versionprotoc会打印 libprotoc 的版本号grpc_cpp_plugin一般没有--version参数直接跑会报用法错误但只要能报出用法而不是「不是内部或外部命令」就说明插件本身是可执行的。这一步过了说明安装产物是完整的。第二步验证 proto 生成链路。拿前面那个greeter.proto重新生成一遍代码然后检查四个输出文件是否都非空dir greeter.pb.cc greeter.pb.h greeter.grpc.pb.cc greeter.grpc.pb.h四个文件大小都不为 0且greeter.grpc.pb.h里能搜到class Greeter和SayHello说明插件工作正常。这一步是最容易被忽略的很多人装完 gRPC 就直接写业务代码结果 proto 生成失败后面全是连锁错误。第三步端到端跑通。先起 server再起 clientclient 输出Hello VS2015就算全通。为了确认不是偶然我会把 server 停掉再跑一次 client这时候 client 应该报连接失败而不是崩溃说明错误处理路径也是通的。验证项通过标准失败时先查protoc 版本打印 libprotoc 版本号PATH 和安装目录插件可执行报用法而非找不到命令bin 目录是否在 PATHproto 生成四个文件非空且含服务类插件路径和 proto 语法端到端client 打印 Hello VS2015端口占用和 DLL 依赖断连处理client 报错不崩溃错误处理代码这套流程我每次在新机器上装完都会走一遍前后不到五分钟但能挡掉后面百分之八十的「明明装好了却跑不起来」。从那以后我每次配 grpc windows vs2015 环境都强制先跑完这三步再动业务代码省下来的排查时间远比这五分钟多。希望帮到你。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
