From 672ee923ca5652e96bfaf3d0ac125adc774ec4bb Mon Sep 17 00:00:00 2001 From: Johannes Schindelin Date: Wed, 10 Jun 2026 17:09:01 +0200 Subject: [PATCH 1/3] 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: From 94548d99f083bc2e81ef661227908394d5c29d20 Mon Sep 17 00:00:00 2001 From: Philip Oakley Date: Sun, 6 Oct 2019 18:40:55 +0100 Subject: [PATCH 2/3] vcpkg_install: detect lack of Git The vcpkg_install batch file depends on the availability of a working Git on the CMD path. This may not be present if the user has selected the 'bash only' option during Git-for-Windows install. Detect and tell the user about their lack of a working Git in the CMD window. Fixes #2348. A separate PR https://github.com/git-for-windows/build-extra/pull/258 now highlights the recommended path setting during install. Signed-off-by: Philip Oakley --- compat/vcbuild/vcpkg_install.bat | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/compat/vcbuild/vcpkg_install.bat b/compat/vcbuild/vcpkg_install.bat index ebd0bad242..bcbbf536af 100644 --- a/compat/vcbuild/vcpkg_install.bat +++ b/compat/vcbuild/vcpkg_install.bat @@ -36,6 +36,13 @@ REM ================================================================ dir vcpkg\vcpkg.exe >nul 2>nul && GOTO :install_libraries + git.exe version 2>nul + IF ERRORLEVEL 1 ( + echo "***" + echo "Git not found. Please adjust your CMD path or Git install option." + echo "***" + EXIT /B 1 ) + echo Fetching vcpkg in %cwd%vcpkg git.exe clone https://github.com/Microsoft/vcpkg vcpkg IF ERRORLEVEL 1 ( EXIT /B 1 ) From b443cc5cffd412af95ec54a3453cf3df80cca87b Mon Sep 17 00:00:00 2001 From: Philip Oakley Date: Sun, 6 Oct 2019 18:43:57 +0100 Subject: [PATCH 3/3] vcpkg_install: add comment regarding slow network connections The vcpkg downloads may not succeed. Warn careful readers of the time out. A simple retry will usually resolve the issue. Signed-off-by: Philip Oakley Signed-off-by: Johannes Schindelin --- compat/vcbuild/vcpkg_install.bat | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/compat/vcbuild/vcpkg_install.bat b/compat/vcbuild/vcpkg_install.bat index bcbbf536af..8330d8120f 100644 --- a/compat/vcbuild/vcpkg_install.bat +++ b/compat/vcbuild/vcpkg_install.bat @@ -80,6 +80,12 @@ REM ================================================================ :sub__install_one echo Installing package %1... + REM vcpkg may not be reliable on slow, intermittent or proxy + REM connections, see e.g. + REM https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/4a8f7be5-5e15-4213-a7bb-ddf424a954e6/winhttpsendrequest-ends-with-12002-errorhttptimeout-after-21-seconds-no-matter-what-timeout?forum=windowssdk + REM which explains the hidden 21 second timeout + REM (last post by Dave : Microsoft - Windows Networking team) + .\vcpkg.exe install %1:%arch% IF ERRORLEVEL 1 ( EXIT /B 1 )