One of the projects I got to work on relied on an C++ REST SDK cpprestsdk from Microsoft, I need to build this library myself as we needed to modify the code a little bit. Though I have been working on C and C++ over the Linux platform for a few years, it’s my very first time working with MSVC over the Windows platform and this library. I knew that Visual C++ projects can be quite challenging to deal with, and as soon as I saw that this library is in maintenance mode, I could feel it would cause a lot of trouble. After spending a few hours with outdated documentation and confusing console outputs, I finally figured out how to build it on Windows 11.

Environment

The machine I have is a Windows 11 x64 machine, with Visual Studio 2022 installed.

The version I was trying to build was the tag v2.10.19.

How to compile

Dependencies

Though it’s provided with some doc telling you how to build everything on different platforms, it didn’t take me much time to figure out it simply won’t work at the first step.

vcpkg install --triplet x64-windows zlib openssl boost-system boost-date-time boost-regex boost-interprocess websocketpp brotli

Visual Studio 2022’s vcpkg disabled classic mode, and the embed vcpkg is just too old to be compiled on Windows 11, so this is not very useful at all. So we will have to install dependencies using the manifest mode.

You will need to create a vcpkg.json file at the project root:

git clone https://github.com/microsoft/cpprestsdk.git
cd cpprestsdk
git checkout origin/v2.10.19
vcpkg new --application

Then modify the newly created vcpkg.json and vcpkg-configuration.json as below:

vcpkg.json

{
  "name": "cpprestsdk",
  "version": "1.0.0",
  "dependencies": [
    "zlib",
    "openssl",
    "boost-system",
    "boost-date-time",
    "boost-regex",
    "boost-interprocess",
    "brotli",
    "websocketpp"
  ]
}

vcpkg-configuration.json

{
  "default-registry": {
    "kind": "git",
    "baseline": "b759049a36728d18260963799a56e6b19cb4a2ef",
    "repository": "https://github.com/microsoft/vcpkg"
  },
  "registries": [
    {
      "kind": "artifact",
      "location": "https://github.com/microsoft/vcpkg-ce-catalog/archive/refs/heads/main.zip",
      "name": "microsoft"
    }
  ]
}

Pay extra attention to vcpkg-configuration.json file. Ensure the baseline property is substituted to match the embed vcpkg’s commit SHA value in the cpprestsdk repo, it will definitely fetch dependencies of the wrong version from the latest vcpkg packages repo. Here in the tag v2.10.19, it would be b759049a36728d18260963799a56e6b19cb4a2ef. It took me quite a while to understand how vcpkg fetches the right version without specifying the version number.

Building

Before starting build, one more step we need to take. We need to lock the toolchain to v141 to let every dependency be happy if you are using a version higher than Visual Studio 2017.

You will need go to the directory vcpkg hosts triplets cmake files, i.e. x:\Microsoft Visual Studio\2022\Professional\VC\vcpkg\triplets on my machine. Create a new triplet named x64-windows-v141.cmake.

set(VCPKG_TARGET_ARCHITECTURE x64)
set(VCPKG_CRT_LINKAGE dynamic)
set(VCPKG_LIBRARY_LINKAGE dynamic)

set(VCPKG_PLATFORM_TOOLSET v141)

Now we can use the Visual Studio’s Cmake to build everything, ensuring you select the triplet we just created as the value for VCPKG_TARGET_TRIPLET.

# at the cpprestsdk repo root
mkdir build
cd build
cmake ../Release -DCMAKE_TOOLCHAIN_FILE="<path to vcpkg/scripts/buildsystems>/vcpkg.cmake" -DVCPKG_TARGET_TRIPLET=x64-windows-v141
cmake --build . --config Release

You may see a lot of tests failed to compile, it’s because <chrono> is not explicitly included in the test code, and was exposed to the test code when it included other std headers. VS 2022 solved such accidental inclusions, making it fail to build. But I didn’t dig deep into it, so there may be other errors popping out.

Thanks to AI, otherwise, it would be really hard to tell what do all of these confusing error logs mean over different compiler versions :( To be honest, the process of building this project really showed me how crazy it would be to switch between different versions of Microsoft’s C++ tool chain. And how annoying bad documentation can be!