From 672ee923ca5652e96bfaf3d0ac125adc774ec4bb Mon Sep 17 00:00:00 2001 From: Johannes Schindelin Date: Wed, 10 Jun 2026 17:09:01 +0200 Subject: [PATCH] ci(vs-build): adapt to Visual Studio 2026 default on windows-latest 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 https://github.com/actions/runner-images/issues/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 889cacb6 (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 Assisted-by: Opus 4.7 --- .github/workflows/main.yml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml index 85cfedf5b0..757784a000 100644 --- a/.github/workflows/main.yml +++ b/.github/workflows/main.yml @@ -196,7 +196,9 @@ jobs: cmake `pwd`/contrib/buildsystems/ -DCMAKE_PREFIX_PATH=`pwd`/compat/vcbuild/vcpkg/installed/x64-windows \ -DNO_GETTEXT=YesPlease -DPERL_TESTS=OFF -DPYTHON_TESTS=OFF -DCURL_NO_CURL_CMAKE=ON - name: MSBuild - run: msbuild git.sln -property:Configuration=Release -property:Platform=x64 -maxCpuCount:4 -property:PlatformToolset=v142 + run: | + $sln = if (Test-Path git.slnx) { 'git.slnx' } else { 'git.sln' } + msbuild $sln -property:Configuration=Release -property:Platform=x64 -maxCpuCount:4 - name: bundle artifact tar shell: bash env: