Harden Windows build setup#840
Harden Windows build setup#840eransha-salvador wants to merge 2 commits intoPowerShell:latestw_allfrom
Conversation
- Prefer VS 2017/2019/2022 over newer installs (e.g. VS 2026) when vswhere reports both, so a host with a newer VS installed alongside VS 2022 still builds with v143. Without this the downstream Select-String version checks miss and the VS 2015 fallback dereferences a null VS140COMNTOOLS. - Pin vcpkg's CMake with VCPKG_VISUAL_STUDIO_PATH and VCPKG_PLATFORM_TOOLSET=v143 so it uses the same toolset as the .vcxproj files, avoiding MSB8040 (Spectre-libs missing for v145) when vcpkg would otherwise pick up a newer VS. - Fall back to the repo root for OpenSSH-build.ps1 -destination when \$env:WORKSPACE is unset. CI still has its WORKSPACE value, and no longer invokes this script directly anyway. - Document Windows build prerequisites in README.txt: VS 2022 Desktop C++ workload, v143 Spectre-mitigated libs, Git, the one-time vcpkg bootstrap/integrate step, and the need to run from an elevated PowerShell.
The .vcxproj files pin PlatformToolset v143, which ships with VS 2022. VS 2017 (v141) and VS 2019 (v142) would need v143 build tools sideloaded to build this, which is a non-default setup — so they shouldn't be treated as equals to VS 2022 in the preference order.
eransha-salvador
force-pushed
the
838-enhance-build-for-windows
branch
from
f32a045 to
c55ef23
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
@eransha-salvador - please review the Contributor License Agreement mentioned above |
There was a problem hiding this comment.
Pull request overview
Hardens the Windows build scripts to consistently select a supported Visual Studio toolset (v143) and improves local usability/documentation for building Win32-OpenSSH.
Changes:
- Prefer VS 2022 for MSBuild discovery and pin vcpkg to the same VS install and
v143toolset. - Make
OpenSSH-build.ps1runnable outside CI by defaulting$destinationwhenWORKSPACEis unset. - Add/expand Windows build prerequisites documentation in
README.txt.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| contrib/win32/openssh/README.txt | Documents Windows build prerequisites and clarifies admin PowerShell requirement. |
| contrib/win32/openssh/OpenSSHBuildHelper.psm1 | Prefers VS 2022 in discovery and pins vcpkg to VS path + v143. |
| contrib/win32/openssh/OpenSSH-build.ps1 | Adjusts default artifact destination when WORKSPACE is not set. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| param ( | ||
| [string] $repolocation = "$PSScriptRoot\..\..\..", | ||
| [string] $destination = "$env:WORKSPACE", | ||
| [string] $destination = $(if ($env:WORKSPACE) { $env:WORKSPACE } else { "$PSScriptRoot\..\..\.." }), |
There was a problem hiding this comment.
With $env:WORKSPACE unset, $destination now defaults to the repo root, which makes the final Compress-Archive write the archive to the same path as the staging directory created earlier ($repolocation\${Bucket}_symbols). That path already exists as a directory, so the archive creation will fail (or overwrite behavior will be inconsistent). Consider defaulting the archive output to a non-colliding filename (e.g., add an extension/suffix) or using a separate output directory when $destination -eq $repolocation.
| # Prefer VS 2022 — the .vcxproj files pin <PlatformToolset>v143</PlatformToolset>, | ||
| # which ships with VS 2022. Older VS (2017=v141, 2019=v142) would need v143 build tools | ||
| # sideloaded; newer VS (e.g. 2026) defaults to v145 which isn't supported here. | ||
| $preferred = @($VSPaths | Where-Object { $_ -match '\\2022\\' }) | ||
| $ordered = $preferred + @($VSPaths | Where-Object { $_ -notmatch '\\2022\\' }) | ||
| foreach ($VSPath in $ordered) { |
There was a problem hiding this comment.
The new ordering only explicitly prefers paths containing \2022\. This doesn't implement the PR goal of preferring older installs (2017/2019/2022) over newer ones, and it may still pick a newer VS first if vswhere returns it earlier (e.g., on hosts without VS 2022). Consider ordering by detected major version (from vswhere JSON / installationVersion) rather than by substring-matching the install path so 2019/2017 are reliably preferred over newer releases when 2022 isn't available.
@microsoft-github-policy-service agree |
|
@microsoft-github-policy-service agree |
1 similar comment
|
@microsoft-github-policy-service agree |
Summary
VCPKG_VISUAL_STUDIO_PATH/VCPKG_PLATFORM_TOOLSET=v143so vcpkg's CMake matches the.vcxprojtoolset.$env:WORKSPACEis unset soOpenSSH-build.ps1is runnable outside CI.README.txt.Fixes PowerShell/Win32-OpenSSH#2434
Test plan
Start-OpenSSHBuildon a host with both VS 2022 and VS 2026 installed; verify v143 toolset is selected and build succeeds.OpenSSH-build.ps1locally (noWORKSPACEset) and verify artifacts land in the repo root.README.txtand build end-to-end.