Improve Visual Studio toolchain detection for Windows builds

[johnml1135]

This PR splits out the Windows build-toolchain reliability work from the local liblcm source-mode changes.

Included in this PR:

• prefer the Visual Studio HostX64/x64 MSVC tool directory in the build environment
• improve nmake.exe discovery in the custom Make MSBuild task
• align dependency verification with the current Windows toolchain expectations

Not included:

• any liblcm source-mode wiring
• VS Code local-mode launch/build flow changes
• DistFiles/Parts/StandardParts.xml

StandardParts.xml was reviewed during the split and left out intentionally. It is not part of the toolchain work, and the added part IDs are not referenced elsewhere on the branch, so it does not belong in this standalone PR.

This PR does not change how FieldWorks resolves liblcm.

Validation:

• split contains only Build/Agent/FwBuildEnvironment.psm1, Build/Agent/Verify-FwDependencies.ps1, and Build/Src/FwBuildTasks/Make.cs
• branch reviewed to keep the split independent of local liblcm workflow changes

---

This change is 

[Copilot]

Pull request overview

This PR improves Windows build-toolchain reliability by preferring the correct MSVC host tool bin directory, making nmake.exe discovery more robust, and updating dependency verification to match current expectations.

Changes:

• Prefer Visual Studio MSVC Hostx64\x64 tool bin directories when resolving build tools.
• Improve dependency verification UX (compact vs detailed) and add an opt-in structured results mode.
• Update WiX dependency detection logic to be more structured (XML-based) and remove legacy NuGet CLI checks.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
Build/Src/FwBuildTasks/Make.cs	Adds MSVC tool-bin discovery under VCINSTALLDIR\Tools\MSVC\*\bin\... and prefers Hostx64/x64 for tool resolution.
Build/Agent/Verify-FwDependencies.ps1	Adds -Detailed / -PassThru, adjusts summary output, and updates WiX detection; removes NuGet CLI check.
Build/Agent/FwBuildEnvironment.psm1	Ensures the preferred MSVC HostX64\x64 bin path is moved to the front of PATH during VS env initialization.

[github-actions]

NUnit Tests

    1 files  ±0      1 suites  ±0   11m 31s ⏱️ + 3m 20s
4 205 tests ±0  4 134 ✅ ±0  71 💤 ±0  0 ❌ ±0 
4 214 runs  ±0  4 143 ✅ ±0  71 💤 ±0  0 ❌ ±0 

Results for commit 631fa8f. ± Comparison against base commit 2f97608.

♻️ This comment has been updated with latest results.

[jasonleenaylor]

I think that this change should be redone to use the microsoft provide vswhere package.

[johnml1135]

Update on the toolchain work:

Managed paths are now covered by the shared Visual Studio helper in Build/Agent/FwBuildEnvironment.psm1, and the scripts that feed the supported build flow now consume it consistently:

• build.ps1, test.ps1, and Build/scripts/Invoke-CppTest.ps1 still initialize through the shared environment module.
• Build/Agent/Setup-FwBuildEnv.ps1 and Setup-Developer-Machine.ps1 now use the shared VS discovery helper instead of their own ad hoc vswhere logic.
• Build/Agent/Setup-InstallerBuild.ps1 no longer prints hardcoded Community-only VsDevCmd paths.
• .vscode/settings.json no longer pins a machine-specific MSBuild path.

For unmanaged/native paths, the remaining work is mostly cleanup and consistency rather than blocking correctness:

• Build/Src/FwBuildTasks/Make.cs should prefer the active toolset before PATH for nmake.exe resolution.
• Build/scripts/Invoke-CppTest.ps1 still has hardcoded C:\BuildTools fallbacks for MSBuild and the Debug CRT.
• The legacy NMake/VCXProj paths and Build/RegFree.targets still have some hardcoded fallback assumptions that could be removed if we want a fully unified native toolchain story.

Net: the managed path is now aligned on one shared discovery model; the native side is functional but still has a few legacy resolution paths that could be simplified in a follow-up.

[jasonleenaylor]

Build/Agent/Setup-InstallerBuild.ps1 line 114 at r4 (raw file):

			Write-Host "[OK] VS Developer environment scripts available" -ForegroundColor Green
		$restoreWrappedCommand = 'cmd /c "call ""{0}"" -arch=amd64 >nul && msbuild Build/InstallerBuild.proj /t:RestorePackages /p:Configuration=Debug /p:Platform=x64"' -f $toolchain.VsDevCmdPath
		$buildWrappedCommand = 'cmd /c "call ""{0}"" -arch=amd64 >nul && msbuild Build/InstallerBuild.proj /t:BuildInstaller /p:Configuration=Debug /p:Platform=x64 /p:config=release /m /v:n"' -f $toolchain.VsDevCmdPath

These two installer commands should be using /p:Configuration=Release

[johnml1135]

@jasonleenaylor addressed in e5ba3a4.

I simplified Build/Agent/Setup-InstallerBuild.ps1 so the installer commands are defined once and reused for both the plain and VsDevCmd-wrapped output paths. They now pass only /p:Configuration=Release; the legacy config value is derived from Configuration by the existing build logic, so we do not need to spell the same setting twice or risk another Configuration=Debug / config=release mismatch.

I also reran ./Build/Agent/Setup-InstallerBuild.ps1 -ValidateOnly locally after the change. The script executed cleanly until the expected missing helper-repo prerequisites on this machine.

[jasonleenaylor]

If you are certain that our current build does not require the 'config' to build the c++ properly then
I had an informational comment about a fragile line which can be addressed at developer discretion.

@jasonleenaylor reviewed 6 files and all commit messages, and made 2 comments.
Reviewable status: 6 of 8 files reviewed, all discussions resolved.

---

Build/Agent/FwBuildEnvironment.psm1 line 111 at r5 (raw file):

    }

    $vcTargetsPath = Join-Path $installationPath 'MSBuild\Microsoft\VC\v170'

Ok, on my second pass I noticed this. I will not hold up the review for it but this path might be a fragile part of this script. The next version may change the 'v170' part so we will either need fallbacks here or it may be possible to get this info from vswhere. This can be a follow up.

[johnml1135]

Follow-up for the v170 fragility note in #766 (review)

I changed the branch so that Build/Agent/FwBuildEnvironment.psm1 no longer hardcodes that path in isolation.

The branch now has a repo-controlled toolchain policy in Build/FieldWorks.Toolchain.props:

• FwVisualStudioVersionRange = [17.0,18.0)
• FwVCTargetsVersion = v170
• FwPlatformToolset = v143
• FwDotNetFrameworkSdkVisualStudioVersion = 17.0

FwBuildEnvironment.psm1 now discovers the Visual Studio installation with vswhere, but only within the configured version range, and derives VCTargetsPath from the shared policy instead of embedding v170 directly. The native .vcxproj files now consume $(FwPlatformToolset), and BuildUtils.cs reads the same policy for the .NET Framework SDK lookup.

That keeps control in the repo when we intentionally move toolchains, instead of floating to whatever is newest on a machine or keeping separate hardcodes in multiple places.

Pushed in a06d110aa.

Validation on this branch:

• PowerShell smoke test confirmed the policy-driven VS discovery and VCTargetsPath resolution.
• Kernel.vcxproj PrepareForBuild succeeded under the VS dev environment with the centralized PlatformToolset.
• A full FwBuildTasks rebuild hit an unrelated existing Output\Debug/xsltc.exe issue, so I narrowed that validation to the toolchain-specific checks above.

[johnml1135]

Validation update after chasing the local failure:

• Pushed f6f16a439 with the verification fixes: native VS Code test tasks now use the current test.ps1 -SkipManaged switch, the whitespace fixer now passes origin/main..HEAD as one Git revision range, and the TonePars test path normalizer no longer strips the user-profile prefix from unrelated worktree paths.
• Local checks now pass:
  • CI: Full local check is clean.
  • Debug build passed with 0 errors / 0 warnings.
  • Release build passed with 0 errors / 0 warnings.
  • Managed tests passed: 4,173 executed / 0 failed.
  • Native tests passed: TestGeneric 30/0/0 and TestViews 292/0/0.
  • Setup: Verify dependencies passed for required and optional dependencies.
• Installer: Validate prerequisites validated VS/MSBuild discovery locally; the remaining local prerequisite failures are missing helper repos on this machine (DistFiles/Helps, Localizations, Localizations/LCM), not a toolchain detection failure.
• Cloud after the push is green: commit messages, check-whitespace, lychee, Flex CI, Publish Test Results, and the published NUnit result (4,116 passed, 71 skipped) all succeeded.

[jasonleenaylor]

@jasonleenaylor reviewed 18 files and all commit messages, and made 1 comment.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on johnml1135).