ci(vs-build): adapt to Visual Studio 2026 default on windows-latest#6275
Merged
Conversation
dscho
force-pushed
the
ci-vs-build-vs2026
branch
from
12a4aa1 to
ff76c9d
Compare
The `windows-latest` runner image migration that began on June 8, 2026 and completes on June 15, 2026 switches the default Visual Studio install from VS 2022 (v17) to VS 2026 (v18), per actions/runner-images#14017. CMake 4.x picks up the new generator name "Visual Studio 18 2026" automatically and, crucially, writes the solution file with the new `.slnx` (XML) extension rather than `.sln`. See https://github.com/Kitware/CMake/blob/v4.3.2/Source/cmGlobalVisualStudioGenerator.cxx#L1147-L1159 where `GetSLNFile()` appends an "x" to the filename when the generator version is `VS18` or newer. As a result, the `MSBuild` step in the `vs-build` job fails with MSBUILD : error MSB1009: Project file does not exist. Switch: git.sln because the file CMake actually wrote is `git.slnx`. An example of the failure can be seen at https://github.com/git-for-windows/git/actions/runs/27264770241/job/80556419519. Teach the step to prefer `git.slnx` and fall back to `git.sln` so that it works on both the new image and any runner still on VS 2022 during the week-long staggered rollout. The conditional is written in PowerShell rather than bash so the step stays on the default shell: `microsoft/setup-msbuild@v3` adds `msbuild` to the Windows `PATH` only, and an MSYS2 bash spawned by the SDK does not pick it up (an earlier attempt at this fix using `shell: bash` failed with `msbuild: command not found`, see https://github.com/git-for-windows/git/actions/runs/27290221733/job/80608493655). Letting MSBuild itself discover the solution by omitting the project argument is not an option here either: CMake emits all `*.vcxproj` files (one per `add_executable`/`add_library`, e.g. `git-daemon.vcxproj`, `common-main.vcxproj`, `ALL_BUILD.vcxproj`, ...) into the same build root as the solution file, and MSBuild's auto-discovery in `ProcessProjectSwitch()` (`dotnet/msbuild`, `src/MSBuild/XMake.cs`) rejects that combination as `AmbiguousProjectError` because it only disambiguates the special case of exactly two projects where one has a `.proj` extension. Additionally, drop the `-property:PlatformToolset=v142` argument that had been carried since 889cacb (ci: configure GitHub Actions for CI/PR, 2020-04-11), when this job was first configured for VS 2019. The VS 2026 install on `windows-latest` only ships the v144 toolset along with a v143 compatibility component (`Microsoft.VisualStudio.Component.VC.14.44.17.14.x86.x64`); v142 is no longer present, so the explicit pin would now also fail in its own right. Removing it lets MSBuild use whatever toolset CMake selected during configuration (v143 on a VS 2022 runner, v144 on a VS 2026 one), which keeps the configure and build steps consistent with each other regardless of which image picked up the job. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Assisted-by: Opus 4.7
dscho
force-pushed
the
ci-vs-build-vs2026
branch
from
ff76c9d to
556da21
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
windows-latestrunner image migration that began on June 8, 2026 and completes by June 15, 2026 swaps Visual Studio 2022 for Visual Studio 2026 by default (see actions/runner-images#14017). That, in turn, leaves thevs-buildjob broken because of two independent things baked into the workflow.First, CMake 4.x now picks up the
Visual Studio 18 2026generator on this image, and that generator writes a.slnx(XML solution) file rather than the classic.sln. The behavior is explicit incmGlobalVisualStudioGenerator::GetSLNFile, which appends"x"to the filename whenever the generator version isVS18or newer. The MSBuild step then trips over the missinggit.sln:A representative failure is actions run 27264770241.
Second, the step has been pinning
-property:PlatformToolset=v142since 889cacb6 (2020), when the job was first wired up for Visual Studio 2019. The new VS 2026 image only ships the v144 toolset plus a v143 compatibility component (Microsoft.VisualStudio.Component.VC.14.44.17.14.x86.x64); v142 is simply not installed any more, so even after the.slnxrename the pin would fail in its own right.This PR therefore changes the MSBuild invocation to reference
git.slnxand drops the v142 toolset pin, letting MSBuild use whatever toolset CMake chose during configuration (v144 on the current image). MSBuild 18, which the new image ships, understands.slnxnatively, so no further plumbing is needed.