Image windows-2022: Microsoft.VCToolsVersion.v143.default.props contains wrong version

[kblaschke]

Description

As described in azure-pipelines-agent issue #4554 and this Developer Community post, the current windows-2022 runner image has a wrong toolset version in the Microsoft.VCToolsVersion.v143.default.props file, leading to linker errors in certain build configurations.

Specifically, linking a static library calling sleep_for into an executable will cause a linker error such as this:

error LNK2019: unresolved external symbol _Thrd_sleep_for referenced in function "void __cdecl std::this_thread::sleep_for<__int64,struct std::ratio<1,1000> >(class std::chrono::duration<__int64,struct std::ratio<1,1000> > const &)" (??$sleep_for@_JU?$ratio@$00$0DOI@@std@@@this_thread@std@@YAXAEBV?$duration@_JU?$ratio@$00$0DOI@@std@@@chrono@1@@Z)

One of my projects exposes the issue in a very reproducible way: https://github.com/kblaschke/frontend-sdl2/actions

There are lots of other reports on GitHub and elsewhere having the same issue, possibly caused by a broken Visual Studio update. Examples:

• Linker Error when using PPLib 2024.2.8 mjansen4857/pathplanner#677
• [OpenAL-Soft]build failure for x64-windows-static-md on Github Actions microsoft/vcpkg#38003

Platforms affected

• Azure DevOps
• GitHub Actions - Standard Runners
• GitHub Actions - Larger Runners

Runner images affected

• Ubuntu 20.04
• Ubuntu 22.04
• macOS 11
• macOS 12
• macOS 13
• macOS 13 Arm64
• macOS 14
• macOS 14 Arm64
• Windows Server 2019
• Windows Server 2022

Image version and build link

Current runner version: '2.315.0'

Example failed build: https://github.com/kblaschke/frontend-sdl2/actions/runs/8619445446/job/23624147736

Is it regression?

2.311.0, https://github.com/kblaschke/frontend-sdl2/actions/runs/7588250886/job/20670360139

Expected behavior

The build should succeed, and the static library linked without an error.

Actual behavior

The build fails due to linker errors, most likely because the different builds steps select different toolset versions due to the broken .props files.

Repro steps

1. Build a static library using C++11 or higher via vcpkg, and use std::this_thread::sleep_for inside a function. The Poco::File class from the POCO framework is the one exposing an issue in my builds for example.
2. Build an executable with CMake and call the according function in the static library.

[erik-bershel]

Hey @kblaschke!

It's notorious bug of Visual Studio when multiple v143 toolsets installed. 😞 I suppose this time mentioned library version changed in the latest toolchain which triggering your issue. We have nothing to do here except remove additional toolsets in order to force users to install it by their own.

Related issues: #9404, #9086, #7867, #7832

I'll keep this item for some time - we'll reinvestigate and possibly reconsider situation around this bug.

[kblaschke]

Thanks for the quick response!

I've been able to fix the build for now using the TheMrMilchmann/setup-msvc-dev@v3 action, but it would be nice to have a default setup that "just works" and simply uses the latest toolset automatically. I'll watch this issue and remove the workaround once this has been solved.

[erik-bershel]

Heads up!
We've decided to remove all the VC components duplicates from the Windows-2022 image to avoid this nasty behaviour. Since it is a breaking change for the part of the community it was decided to take a long break before the rollout. Please, track progress here: #9701

Thanks to everyone involved in the related issues for your patience and information provided.