Repository navigation
fix(windows): detect MSBuild in VS BuildTools editions - #117
Merged
Merged
Conversation
- vswhere: add -products * so BuildTools installs are visible, and require Microsoft.VisualStudio.Component.VC.Tools.x86.x64 to guarantee a C++ toolchain is present (bare MSBuild is not enough to build the addon) - fallback: scan roots x years x editions (incl. BuildTools) instead of a hardcoded list that only covered Enterprise/Professional/Community - derive PlatformToolset from the VS year in the MSBuild path (2017 -> v141, 2019 -> v142, default v143) instead of hardcoding v143, which fails with MSB8020 on VS 2019 Fixes oransel#116
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.
Fixes #116.
Problem
src/lib/build.jsfails withMSBuild not found. Please install Visual Studio Build Tools.even when Build Tools is installed, because:-products *, so BuildTools installations are invisible to it (vswhere only reports full VS editions by default).possiblePathsfallback list covers onlyEnterprise/Professional/Communityeditions — noBuildToolsentries, even though Build Tools is the edition Microsoft recommends for CI and whatchoco install visualstudio2022-workload-vctools/ winget produce.PlatformToolset=v143is hardcoded, which fails withMSB8020when MSBuild is found under VS 2019 (v142) or VS 2017 (v141).Changes
-products *and requireMicrosoft.VisualStudio.Component.VC.Tools.x86.x64instead ofMicrosoft.Component.MSBuild— this both finds BuildTools installs and guarantees a C++ toolchain is present (bare MSBuild without VC tools cannot build the addon).Program Files/Program Files (x86)× years2022/2019/2017× editionsEnterprise/Professional/Community/BuildTools(plus the legacyMSBuild\14.0paths). 2017 uses theMSBuild\15.0\Binlayout, 2019+ useMSBuild\Current\Bin.PlatformToolsetfrom the VS year in the resolved MSBuild path (2017 → v141,2019 → v142, defaultv143) instead of hardcodingv143.Verification
node --check src/lib/build.jspasses.C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools, MSVC 14.44, SDK 10.0.26100.0): the vswhere path now resolves the BuildTools install directly — no directory-junction workaround (mklink /J ... Community ... BuildTools) needed anymore.patchedDependencies) in a production project since 2026-08 across VS 2019 BuildTools and VS 2022 BuildTools machines, Windows and Docker/Linux CI.