This directory contains MS Visual Studio project & solution files.
#Supported Visual Studio versions
Currently supported versions are Visual Studio 2013 (our primary focus) and 2010.
#Building We are using NuGet to pull zlib and openssl dependencies. If you don‘t have Visual Studio NuGet plugin installed, you’ll need to download nuget.exe from the web and manually restore the NuGet packages.
> REM Run from this directory. > REM No need to do this if you have NuGet visual studio extension. > nuget restore grpc.sln
After that, you can build the solution using one of these options:
grpc.slnwith Visual Studio and hit “Build”.
msbuild grpc.sln /p:Configuration=Debug
#C/C++ Test Dependencies
/third_party/gtest/(the folder will end up with
/codegear/, etc. folders in it).
/msvc/, and save over the first solution (you will have to change it from read-only). change all projects to use
/MDd(Property Pages - C/C++ - Code Generation - Runtime Library) and build. This is a “multithreaded debug” setting and it needs to match grpc.
cmake <path to gtest directory>
.slnand fill up the
/third_party/gflags/include/gflags/directory with headers
/third_party/are not used). If it doesn't work use
tools->nuget...->manage.... The packages are put in
#C/C++ Test Solution/Project Build Steps
"debug": true,to the top of build.json. This is the base file for all build tracking, see templates for more information
"debug": true,gets picked up by
/tools/buildgen/plugins/generate_vsprojects.py. It tells the script to add visual studio GUIDs to all projects. Otherwise only the projects that already have GUIDs in build.json will be built
/templates/vsprojects/generate_debug_projects.shto make debug templates/projects. This runs a regular visual studio buildgen process, which creates the
.slnfile with all of the new debug projects, then uses git diff to find the new project names from the
.slnthat need templates added. It builds the new templates based on the diff, then re-runs the visual studio buildgen, which builds the vs projects for each of the new debug targets
/vsprojects/folder to your windows build setup (assuming this was built on linux in order to have easy access to python/mako and shell scripts)
/test/in-place. there might be a better place to put them that mirrors what happens in the linux build process (todo)
.protofile gets built into a
.pb.h. These are included in each test project in lieu of the
.protoincludes specified in
build.json. This substitution is done by
/test/folder in order to get the new files (assuming this was built on linux in order to have an easy protobuf+grpc plugin installation)
#Making and running tests with
make.bat both rely on
/vsprojects/grpc.mak, an NMAKE script that includes C/C++ tests in addition to the base grpc projects. It builds the base projects by calling grpc.sln, but most things are built with a command line similar to a makefile workflow.
buildtests: builds all tests
buildtests_c: just c tests
buildtests_cxx: just c++ tests
run_tests.py on windows:
run_tests.pydetects that it's running on windows it calls
make.batto build the tests and expects to find tests in
run_tests.py -l c: run c language tests
run_tests.py -l c++: run c++ language tests
run_tests.pydoesn't normally show build steps, so if a build fails it is best to fall back to
make.batfails, it might be easier to open up the
.slnfile in the visual studio gui (see above for how to build the test projects) and build the offending test from its project file. The
.makand project file templates are slightly different, so it's possible that a project will build one way and not another. Please report this if it happens.
It can be helpful to disable the firewall when running tests so that 400 connection warnings don't pop up.
Individual tests can be run by directly running the executable in
/vsprojects/run_tests/ (this is
/bins/opt/ on linux). Many C tests have no output; they either pass or fail internally and communicate this with their exit code (
run_tests.py will fail if it can't build something, so not-building tests are disabled with a “platforms = posix” note in build.json. The buildgen tools will not add a test to a windows build unless it is marked “windows” or has no platforms identified. As tests are ported they will get this mark removed.
For generating service stub code, gRPC relies on plugins for
protoc (the protocol buffer compiler). The solution
grpc_protoc_plugins.sln allows you to build Windows .exe binaries of gRPC protoc plugins.
third_party\protobuf\cmake\README.mdto create Visual Studio 2013 projects for protobuf.
$ cd third_party/protobuf/cmake $ cmake -G "Visual Studio 12 2013"
third_party\protobuf\cmake\protobuf.sln and build it in Release mode. That will build libraries
libprotoc.lib needed for the next step.
vsprojects\grpc_protoc_plugins.sln and build it in Release mode. As a result, you should obtain a set of gRPC protoc plugin binaries (
#Building using CMake (with BoringSSL)
choco install activeperl)
choco install ninja)
choco install golang)
choco install yasm)
> md .build > cd .build > call "%VS140COMNTOOLS%..\..\VC\vcvarsall.bat" x64 > cmake .. -GNinja -DCMAKE_BUILD_TYPE=Release > cmake --build .