Document Visual Studio 2022 and 2026 Windows builds#1458
Open
bmehta001 wants to merge 14 commits into
Open
Conversation
Clarify the VS2019/VS2022/VS2026 command-line build entry points, avoid legacy .NET Framework 4.0 projects in VS2022+ wrappers, and make solution-level :Build targets work through RunMsBuild. Files changed: - docs/cpp-start-windows.md - build-all.bat - build-all-v143.bat - build-all-v145.bat - tools/RunMsBuild.bat - tools/setup-buildtools.cmd - tools/vcvars.cmd - tools/.vsconfig.vs2022 - tools/.vsconfig.vs2026 - Solutions/before.targets Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
bmehta001
changed the title
Contributor
There was a problem hiding this comment.
Pull request overview
Adds Windows build documentation and tooling support for Visual Studio 2022 and the upcoming VS2026 (v145), plus a couple of related build-script fixes that unblock VS2022/VS2026 command-line builds.
Changes:
- Document VS2019/VS2022/VS2026 build wrappers and add
build-all-v145.bat; teachvcvars.cmdto detect VS2022 Professional and VS2026 (including theMicrosoft Visual Studio\18\*install path). - Skip legacy .NET Framework 4.0 targets (
net40,SampleCsNet40) on VS2022/VS2026 viaSKIP_NET40_BUILD, and add av145/VS2026 mapping inSolutions/before.targets. - In
RunMsBuild.bat, normalize solution-level:Buildtargets (strip the:Buildsuffix) and fix theif ("%~4" == "")syntax; insetup-buildtools.cmd, use the existing.vsconfig.vs%VSVERSION%naming and add.vsconfig.vs2022/.vsconfig.vs2026.
Reviewed changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| tools/vcvars.cmd | Detects VS2022 Professional, VS2022 BuildTools, and VS2026 (incl. \18\ install paths). |
| tools/setup-buildtools.cmd | Uses .vsconfig.vs%VSVERSION% matching the actual file naming scheme. |
| tools/RunMsBuild.bat | Normalizes name:Build targets to name; fixes if syntax; propagates exit code. |
| tools/.vsconfig.vs2022 | New VS2022 component manifest. |
| tools/.vsconfig.vs2026 | New VS2026 component manifest. |
| Solutions/before.targets | Maps VisualStudioVersion=18.0 to PlatformToolset=v145. |
| docs/cpp-start-windows.md | Documents the per-toolset build-all wrappers and the .NET 4.0 caveat. |
| build-all.bat | Conditionally includes net40 and SampleCsNet40 based on SKIP_NET40_BUILD. |
| build-all-v143.bat | Sets SKIP_NET40_BUILD=1 for VS2022. |
| build-all-v145.bat | New VS2026/v145 wrapper that skips .NET 4.0 targets. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
pablo-msft
approved these changes
Jun 2, 2026
Clarify the Windows Visual Studio build entry point by moving the build matrix implementation to build-all-windows.bat while keeping build-all.bat as a compatibility wrapper. Update version-specific wrappers, CI, helper scripts, and docs to call the clearer name. Also clarify that MFC/ATL Visual Studio components remain intentional because SampleCppMini uses static MFC. Validation: - git diff --check - build-all-v142.bat Solutions\build.compact-dll.props smoke with all build legs skipped confirmed custom props forwarding - material self-review found no remaining issues Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Resolve the Solutions/before.targets conflict in favor of main's cascading VersionGreaterThanOrEquals PlatformToolset mapping: it already maps VS2026 (18.0) to v145 -- this PR's goal -- and future-proofs newer VS versions, superseding this branch's exact-equality mapping. The shared v141 fallback is unchanged. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Addresses code-review findings on the new Windows build CI: - build-windows-vs2022.yaml ran build-all-windows.bat with v143/vs2022 but without SKIP_NET40_BUILD, so it tried to build the legacy net40 / SampleCsNet40 projects that VS2022 cannot build (and that the docs say are skipped). Add SKIP_NET40_BUILD: 1 to match the canonical build-all-v143.bat. - build-all-windows.bat called tools\RunMsBuild.bat ~12 times with no errorlevel check between them, so only the last build's exit code reached the caller; an intermediate config failure was swallowed and the gating CI job could report success on a broken build. Add 'if errorlevel 1 exit /b 1' after each call to fail fast. (Pre-existing in build-all.bat, but newly load-bearing now that a CI gate runs this script; verified the swallowing and the fix with an isolated batch repro.) - Remove continue-on-error: true from the Checkout step so a failed checkout fails the job. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…vsconfig The vs2022/vs2026 component configs only listed the bare Microsoft.VisualStudio.Component.Windows10SDK; since setup-buildtools.cmd applies them with --quiet and no --includeRecommended, a fresh install could end up with no concrete Windows SDK and fail to build. Add the explicit Windows11SDK.22621 component (the 10.0.22621 platform SDK the repo's CodeQL workflow already pins via WindowsSDKVersion: 10.0.22621.0), mirroring how .vsconfig.vs2019 pairs the bare component with a concrete Windows10SDK.18362. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…dows.bat - docs/cpp-start-windows.md: drop 'win32-cs' from the list of legacy .NET 4.0 projects the VS2022/2026 wrappers skip. MSTelemetrySDK.sln only contains net40 and SampleCsNet40 (gated by SKIP_NET40_BUILD); win32-cs lives in a separate Solutions/win32-cs solution and is not part of the SDK build matrix. - build-all-windows.bat: use 'cd /d "%~dp0"' so the script reliably changes drive and tolerates spaces when invoked from another drive/working directory. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The VS-version wrappers (build-all-v142/v143/v145.bat) called build-all-windows.bat by bare relative name, and tools\build-Win10-compact-exp.cmd used 'cd ..' + a CWD-relative call. Invoked from another drive/working directory (e.g. via an absolute path), the sibling script wouldn't be found. Call it via a %~dp0-relative absolute path instead so the wrappers work from any CWD: - build-all-v142/v143/v145.bat: call "%~dp0build-all-windows.bat" %* - build-Win10-compact-exp.cmd: drop the fragile 'cd ..'/%CD% and call "%~dp0..\build-all-windows.bat" with the props file as a %~dp0-relative path. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
vcvars.cmd sets VSTOOLS_NOTFOUND and exits 0 when it can't find any Visual Studio install, but RunMsBuild.bat didn't check it and went straight to msbuild, so a developer with no/undetected VS only saw a cryptic "'msbuild' is not recognized". Check VSTOOLS_NOTFOUND after calling vcvars and print an actionable error (install VS with the C++ workload, or run setup-buildtools.cmd, or set VSTOOLS_VERSION) before aborting. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
vcvars.cmd's label cascade silently moves forward when the requested Visual Studio isn't installed (e.g. a vs2022 request ends up on vs2026). Combined with the version wrappers pinning PlatformToolset (v143/v145), that mismatch surfaces later as a confusing toolset error from msbuild. Capture the explicitly requested version and, once configuration succeeds, print a clear warning when the detected VS differs from what was asked for. The configured path now returns a deterministic exit 0 (callers key off VSTOOLS_NOTFOUND, not the exit code). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot round: vcvars.cmd set VSTOOLS_NOTFOUND=1 on the not-found path but never cleared it on success, so a stale value left in the shell by a previous failed run could make RunMsBuild.bat's new guard abort a build even when VS is present. Clear VSTOOLS_NOTFOUND at vcvars.cmd entry (only the not-found path sets it now) and check the explicit ==1 value in RunMsBuild.bat instead of mere existence. Verified at tools/vcvars.cmd entry and tools/RunMsBuild.bat:17. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot round: clearing only VSTOOLS_NOTFOUND wasn't enough. Callers such as tools\setup-buildtools.cmd gate on if exist "%VSINSTALLDIR%" and use %VSVERSION% for the .vsconfig path, so a stale VSINSTALLDIR/VSVERSION/VSDEVCMD left in the shell (or caller environment) could make them act on the wrong install after a failed detection. Reset VSINSTALLDIR, VSDEVCMD and VSVERSION alongside VSTOOLS_NOTFOUND at entry so each run starts from a fully clean detection state; only the matching detection path repopulates them. Verified: stale VSINSTALLDIR is replaced with the real path on success and left empty when detection doesn't match (tools/setup-buildtools.cmd:42,44). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
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
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.
Summary
Addresses the VS2022/VS2026 Windows build documentation gap from #1260 and keeps related Windows build-script fixes in one focused PR.
build-all-v145.batfor VS2026/v145 and teachvcvars.cmdto find VS2026 installs.:Buildtargets intools/RunMsBuild.batso project builds work consistently.setup-buildtools.cmdto use the existing.vsconfig.vs*naming scheme and add VS2022/VS2026 configs.Validation
git diff --checktools\RunMsBuild.bat x64 Release sqlite:Buildwith VS2026/v145tools\RunMsBuild.bat x64 Release "sqlite:Build,zlib:Rebuild"with VS2026/v145.vsconfig.vs2026.Fixes #1260
Notes: