Default Windows CI builds to Visual Studio 18 2026#6100
Merged
Conversation
GitHub's windows-2025 and windows-latest hosted runner images no longer ship Visual Studio 17 2022, so the hard-coded CMake generator string fails with 'could not find any instance of Visual Studio' on every Windows build job that targets those images (see #6098). Make Visual Studio 18 2026 the default CMake generator everywhere, and use the existing (previously unused) -Generator parameter of build.ps1 to override back to "Visual Studio 17 2022" for jobs still pinned to windows-2022 (kept as a backup image and required for kernel builds until the WDK is available on windows-2025). Changes: - scripts/build.ps1: default $Generator -> "Visual Studio 18 2026". - CMakePresets.json: win-base preset generator -> "Visual Studio 18 2026". - docs/BUILD.md: add a VS 2026 example alongside the existing VS 2022 one. - .github/workflows/build-reuse-win.yml: default `os` input -> windows-2025 and pass `-Generator "Visual Studio 17 2022"` (and the same value for the external platform test CMake invocation) only when the caller pins `os` to windows-2022. - .github/workflows/test-down-level.yml: same conditional override for the Release build step when the matrix entry targets windows-2022. Kernel builds (build-reuse-winkernel.yml) drive msbuild directly and are unaffected. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Two fixes for the cargo windows-latest failure ("Could not create named
generator Visual Studio 18 2026"):
* Move Install Perl / Install NASM ahead of Prepare Machine in
cargo.yml, matching the existing order in build-reuse-win.yml.
shogo82148/actions-setup-perl ships Strawberry Perl, which prepends
an older cmake.exe to PATH. Running it before Prepare Machine lets
Install-CMake see the older cmake during its version check and
correctly prepend the modern one in front for subsequent steps.
* Soften the "system cmake is already current" path in Install-CMake:
emit a ::warning:: + Write-Warning instead of ::error:: +
Write-Error, and continue without installing. This avoids polluting
alternative CI environments (where a recent system cmake is already
acceptable and installing a different one may not be) with a hard
error annotation.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
CMake 4.x stops tolerating backslashes that look like invalid escape sequences when expanding strings into generated install() scripts. Rust's cmake crate passes QUIC_OUTPUT_DIR as a Windows native path (e.g. "D:/.../out\lib"); CMake 4.x then errors out on the generated src/bin/cmake_install.cmake with: Invalid character escape '\l' while parsing "D:/.../out\lib/msquic.lib". This only affects the static configuration on Windows, because the install rule for the monolithic static library is the first one that references the QUIC_OUTPUT_DIR-derived path verbatim. Normalize QUIC_OUTPUT_DIR with file(TO_CMAKE_PATH) right after it is cached so all subsequent uses see the canonical forward-slash form. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Revert the CMakeLists.txt normalization added in 8a094cb and instead fix the source: Rust's cmake crate was passing a Windows-native path (out\lib) because we built it with Path::join after normalizing out_dir. CMake 4.x then rejects "\l" as an invalid character escape when the path is emitted into a generated install() script. Build the path as a String from the already-normalized out_dir so forward slashes are preserved end to end. No CMake-side workaround is needed, and the previous workaround broke Linux/macOS configure because file(TO_CMAKE_PATH) splits on `:` and shredded the embedded $<IF:$<CONFIG:Debug>,...> generator expression. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #6100 +/- ##
==========================================
- Coverage 85.89% 85.76% -0.13%
==========================================
Files 60 60
Lines 18847 18847
==========================================
- Hits 16189 16165 -24
- Misses 2658 2682 +24 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
VS 2026's STL added a new `annotate_optional` marker (compile-time detect_mismatch check). In the external platform test build, gtest is built fresh via FetchContent without ASan, so its objects have annotate_optional=0. The test executable inherits /fsanitize=address from msquic::msquic/msquic::platform via INTERFACE_COMPILE_OPTIONS (exported by cmake --install), so its objects have annotate_optional=1. That mismatch causes LNK2038 when linking gtest.lib against main.obj. Define _DISABLE_OPTIONAL_ANNOTATION on msquicplatformtest alongside the existing _DISABLE_VECTOR_ANNOTATION / _DISABLE_STRING_ANNOTATION so the test side stays at 0 and matches gtest. With VS 2022 this marker did not exist; VS 2025 (16.11+) and VS 2026 ship it. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- scripts/build.rs: keep out_dir as a Path and use Path::join, then normalize backslashes only at the cmake .define() call (per review comment). - scripts/prepare-machine.ps1: drop the second paragraph of the Install-CMake header comment. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
guhetier
commented
Jun 15, 2026
anrossi
reviewed
Jun 15, 2026
The windows-2025 (VS2026) runner image ships CMake 4.3.3 at C:\Program Files\CMake\bin, which already satisfies the >= 4.2 requirement of the Visual Studio 18 2026 generator. The Install-CMake helper in prepare-machine.ps1 was downloading the same version redundantly because Strawberry Perl (added to PATH by shogo82148/actions-setup-perl) bundles an older cmake.exe that shadows the image's cmake in `Get-Command cmake.exe` lookups. Drop the helper entirely and instead add a small workflow step that prepends `C:\Program Files\CMake\bin` to PATH after Perl is installed, so the image's modern CMake wins for subsequent steps. This shaves ~30s off every Windows job that runs prepare-machine and removes one source of fragility (the version pin and download URL). This change is easy to roll back if needed: revert this commit and the helper returns intact. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
guhetier
commented
Jun 15, 2026
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
anrossi
approved these changes
Jun 16, 2026
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
2 participants
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.
Description
GitHub's
windows-2025andwindows-latesthosted runner images no longer ship Visual Studio 17 2022. Every Windows build job that targets those images currently fails with:This change:
Visual Studio 17 2022for jobs that are still pinned towindows-2022(which will soon be out of support).Testing
CI now succeeds
Documentation
docs/BUILD.mdgains a VS 2026 example block. No other doc impact.