Fix razzle.cmd MSBuild detection silently failing on VS 2026 (18.x)

[Dinah Xiaoman G (DinahK-2SO)]

Summary

razzle.cmd could report Could not find MSBuild despite a valid Visual Studio installation, unless MSBuild was already available in PATH.

Root Cause

MSBuild discovery used this command:

for /f ... in (`"%VSWHERE%" ... -version "[17.0,19.0)" ...`) do (

for /f executes the command between backticks through a nested cmd.exe /c. Because the command begins with a quoted executable path and also contains the quoted version range, the special quote-handling rules of cmd.exe /c cause the command to be parsed incorrectly.

Consequently, the ) in "[17.0,19.0)" is interpreted as command syntax instead of part of the version argument. The vswhere command fails and leaves MSBUILD unset.

How This Slipped Through Testing

During development of the previous change, an intermediate version was tested in a regular cmd:

for /f "usebackq tokens=*" %%B in (`%VSWHERE% -latest -prerelease -products * -requires Microsoft.Component.MSBuild -version "[17.0,19.0)" -find MSBuild\**\Bin\MSBuild.exe 2^>nul`) do

It worked because %VSWHERE% was not quoted, where there's only one pair of " and cmd.exe can parse it as expected.

I later added quotes around %VSWHERE% to support paths containing spaces, which caused the regression, but I did not retest the exact final command through the affected MSBuild discovery path.

Most of my local usage ran razzle.cmd from a Visual Studio Developer Command Prompt. Because MSBuild was already in PATH, the script was always successful and the affected discovery step was skipped.

Fix

The updated script runs vswhere directly and redirects its output to a temporary file. It then reads that file with for /f.

This removes the nested cmd.exe /c quoting ambiguity while continuing to support paths containing spaces or parentheses.

This issue was originally found and fixed in microsoft/intelligent-terminal#497; applying the same fix here.

References and Relevant Issues

Detailed Description of the Pull Request / Additional comments

Validation Steps Performed

Verified this PR on below 3 scenarios:

1. in a brand new environment with no Visual Studio or msbuild installed.
   It throws the expected error:
   Could not find vswhere on your machine ...
   

2. in an environment with Visual Studio installed but not added into PATH.
   It finds the msbuild and set its variable as expected.
   

3. in Visual Studio's Developer Command Prompt, where msbuild's already in PATH:
   It sets the msbuild variable as expected.
   

PR Checklist

• Closes #xxx
• Tests added/passed
• Documentation updated
  • If checked, please file a pull request on our docs repo and link it here: #xxx
• Schema updated (if necessary)

[Dinah Xiaoman G (DinahK-2SO)]

Hello Leonard Hecker (@lhecker) and Dustin L. Howett (@DHowett) , please take a loook at this update.

[Dustin L. Howett (DHowett)]

Before we consider this, can you explain to me how you validated your prior pull request to this file before submitting it to us if it was so critically broken?

[Dustin L. Howett (DHowett)]

What I mean, btw, is that... I saw that you mentioned you ran it from a developer command prompt session, but you were changing code that was practically unreachable in that session. How can we be sure that it works this time?

[Dustin L. Howett (DHowett)]

And, why should we not just delete these helpers (/cc Mike Griese (@zadjii-msft))?

[Dinah Xiaoman G (DinahK-2SO)]

Hi Dustin L. Howett (@DHowett) ,

I saw that you mentioned you ran it from a developer command prompt session, but you were changing code that was practically unreachable in that session.

This is my mistake. I am sorry. 😢

I should have explicitly tested the final version from a regular cmd.exe with MSBuild absent from PATH.

How can we be sure that it works this time?

For this revision, I tested in these scenarios:

• A regular cmd window with Visual Studio installed and MSBuild absent from
  PATH. This exercises the affected discovery path and resolves MSBUILD to
  an existing MSBuild.exe.
• A Visual Studio Developer Command Prompt with MSBuild already in PATH. This
  verifies the existing fast path.
• An environment without Visual Studio or MSBuild. This fails with the expected
  diagnostic instead of continuing with an invalid environment.

I included the results in the PR description.
Please review them when you have a moment. Dustin L. Howett (@DHowett)

I apologize for the additional investigation and review work it caused.