mirror of
https://github.com/microsoft/PowerToys.git
synced 2026-07-08 19:40:01 +02:00
1744bdecd8
## Summary of the Pull Request Fixes `tools\build\build-common.ps1` so a clean `tools\build\build-essentials.cmd` (or `build.ps1`) run discovers and uses **Visual Studio 2026 Insiders** without any manual `Enter-VsDevShell` preamble. Today the script lands on the first VS 2022 BuildTools instance it finds (which lacks the C++ workload) and every native `.vcxproj` errors with `MSB4086: $(PlatformToolsetVersion) evaluates to ""` during NuGet restore. Two scoped commits, **only `tools\build\build-common.ps1` is touched** (+58 / −36 net). ## PR Checklist - [ ] Closes: #xxx - [x] **Communication:** I''ve discussed this with core contributors already. If the work hasn''t been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places (n/a — build-script change only) - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx ## Detailed Description of the Pull Request / Additional comments ### What''s broken `build-common.ps1`''s `vswhere` lookup runs **without `-prerelease`**, so VS 2026 Insiders / Preview installs are invisible to it. The explicit fallback path list also only contains VS 2022 entries. On a machine that has VS 2022 BuildTools (typical for CI hosts and many dev boxes) but only has VS 2026 in *Insiders* form, the script: 1. Picks `C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools` because it''s a candidate `vswhere` returned and it''s in the fallback list. 2. Enters its DevShell — but BuildTools has no C++ workload installed, so `$(VCToolsInstallDir)` and `$(PlatformToolsetVersion)` are unset. 3. NuGet restore over `PowerToys.slnx` fans out to every `.vcxproj` and they each hit `Microsoft.CodeAnalysis.targets(401,15): error MSB4086: A numeric comparison was attempted on "$(PlatformToolsetVersion)" that evaluates to "" instead of a number, in condition "''$(PlatformToolsetVersion)''<''120''".` The build dies before any project compiles. This was reproduced today against `origin/main` — confirming this is a pre-existing breakage independent of any in-flight feature work. ### What this PR changes Commit **`30acf72c` — Fix build scripts to discover VS 2026 / Insiders installations** - Adds `-prerelease` to `vswhere` calls, tried **before** the stable lookup so prerelease VS is preferred when it''s the only one with a working C++ workload. - Adds VS 2026 year-name and internal-version (`18\Insiders`) paths to the explicit fallback list. - Keeps VS 2022 paths as the final fallback so existing setups keep working. - Priority order: `prerelease+VC tools` → `prerelease` → `stable+VC tools` → `stable`. Commit **`18b27209` — build: simplify VS environment initialization with VS2022/VS2026 support** - Adds `-prerelease` to `vswhere` (consolidates with the above; the prerelease query subsumes the stable one now). - Restricts the SKU query to `Community` / `Professional` / `Enterprise` (explicitly excludes `BuildTools`) so the script can no longer accidentally pick a SKU without the C++ workload. - Reduces vswhere from **4 calls to 2**. - Removes the destructive BuildTools env-var cleanup block (no longer needed once vswhere refuses to return BuildTools in the first place). - Adds `VsDevCmd.bat` exit-code validation so a partial DevShell init fails loudly instead of silently producing a half-initialized environment. - Adds VS 2022 / VS 2026 Preview entries to the explicit fallback list. ### Why two commits instead of a squash The first commit is the minimum-viable fix that addresses the reported MSB4086 failure. The second commit is a follow-up cleanup that''s only safe **once** prerelease is preferred and BuildTools is excluded. Splitting them keeps each commit independently revert-able if a regression shows up on a specific dev environment shape. ## Validation Steps Performed | Step | Result | |---|---| | Reproduce on `main`: cold `tools\build\build-essentials.cmd` in a non-DevShell PowerShell | **MSB4086** on `Microsoft.CommandPalette.Extensions.vcxproj`, `Microsoft.Terminal.UI.vcxproj`, `PowerToys.MeasureToolCore.vcxproj`, `PowerRenameUI.vcxproj` — confirmed broken | | With this branch checked out: same cold `build-essentials.cmd` invocation | `[VS] vswhere found: ... C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe` → `[VS] Checking candidate: C:\Program Files\Microsoft Visual Studio\18\Insiders` → `[VS] Entered Visual Studio DevShell at C:\Program Files\Microsoft Visual Studio\18\Insiders` — VS 2026 Insiders selected directly, restore step proceeds past the MSB4086 wall | | Manual workaround pre-init via `Import-Module Microsoft.VisualStudio.DevShell.dll` + `Enter-VsDevShell` | Now **unnecessary** — the script self-initializes correctly | After this fix, the next failure mode the build hits is unrelated NuGet feed coverage for in-flight WinAppSDK upgrade work, which is the gated dependency this PR was extracted from to keep this change atomic. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>