Two 18.x installs coexisted: VS2026 Community (full IDE, has VC v180)
and a BuildTools at (x86)\Microsoft Visual Studio\18\BuildTools that
has MSBuild but NO VC v180 targets. The vswhere query only required
Microsoft.Component.MSBuild, so -latest could (and did) return the
C++-less BuildTools -> MSB4019. Also require
Microsoft.VisualStudio.Component.VC.Tools.x86.x64 so only installs
with the C++ toolset match; the broken BuildTools is excluded and
2026\Community is selected. CI VM BuildTools has the C++ workload so
it still matches.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
VS2026 ships on the prerelease channel; vswhere omits it unless
-prerelease is given. Without it _find_msbuild_via_vswhere returned
nothing, so the path fallback picked an incomplete
(x86)\Microsoft Visual Studio\18\BuildTools install (MSBuild present
but no VC v180 targets) -> MSB4019 on hosts that have VS2026 IDE but
not BuildTools. -prerelease is harmless on the CI VM (BuildTools is
found regardless).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
When --dist is passed (forwarded by build_plugin.py to the per-version
script), built nsis7z.dll files are copied to <repo>/dist/<config>
instead of <repo>/plugins/<config>. Lets CI collect a clean dist/
tree without touching the committed plugins/ dir. Windows
(2601_vs2026) and Linux build paths both supported.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- Add tools/legacy/build_plugin_2601_vs2026.py: Windows build script for
7-zip 26.01 using VS2026 toolset (v145), adapted from the zstd equivalent.
Points to versions/26.01-bundle/ as the project root.
- Update build_plugin.py:
- Add LINUX_SCRIPT reference to tools/linux/build_plugin_linux.py.
- Add '26.01' to WINDOWS_SCRIPTS with v2026 entry pointing to the new
script (v2022 remains None; 26.01 requires v145 minimum).
- Add '26.01' to LINUX_SUPPORTED_7ZIP set.
- Add '26.01' to argparse choices.
Simone