AOT publish from `dotnet publish` generates error message, but seems to complete anyway

[smaillet]

Description

When running dotnet publish on my project it will generate the following output:

The input line is too long.
The syntax of the command is incorrect.

After sleuthing with diagnostics, it seems to be coming from an attempt to run a packaged version of findvcvarsall.bat

                   Task "Exec" (TaskId:389)
                     Task Parameter:StandardOutputImportance=Low (TaskId:389)
                     Task Parameter:Command="D:\.nuget\packages\microsoft.dotnet.ilcompiler\9.0.4\build\findvcvarsall.bat" x64 (TaskId:389)
                     Task Parameter:ConsoleToMSBuild=True (TaskId:389)
                     Task Parameter:IgnoreExitCode=True (TaskId:389)
                     "D:\.nuget\packages\microsoft.dotnet.ilcompiler\9.0.4\build\findvcvarsall.bat" x64 (TaskId:389)
                     The input line is too long. (TaskId:389)
                     The syntax of the command is incorrect. (TaskId:389)
                     The command ""D:\.nuget\packages\microsoft.dotnet.ilcompiler\9.0.4\build\findvcvarsall.bat" x64" exited with code 255. (TaskId:389)
                     Output Property: _FindVCVarsallOutput=The input line is too long.;The syntax of the command is incorrect. (TaskId:389)
                     Output Property: _VCVarsAllFound=255 (TaskId:389)
                   Done executing task "Exec". (TaskId:389)
                   Task "Error" skipped, due to false condition; ('$(_VCVarsAllFound)' == '1') was evaluated as ('255' == '1').

Reproduction Steps

syntax of command run:

dotnet publish -r win-x64 .\<myproj>.csproj

Expected behavior

It should complete without errors or warnings that are vague or unactionable.

Actual behavior

As described, it indicates something is wrong, but doesn't say what that something is, even though it "seems" to produce a working output. (This does NOT inspire one with much in the way of confidence in said output!)

Regression?

No response

Known Workarounds

No response

Configuration

.NET 9
Windows 10 Version 22H2 (OS Build 19045.5737) [All Updates applied]
AMD64
[Unknown if related to this config only, I have no other configs to try]

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

[MichalStrehovsky]

I can repro this by opening a command prompt and running

"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\vc\Auxiliary\Build\vcvarsall.bat" amd64

five times. Looks like this is a common problem with vcvarsall - it will start failing when PATH is too long (and has no trouble adding duplicates to PATH) but still exits with 0.

Are you running from a clean command prompt or is that already some kind of developer command prompt? How long is your PATH?

[smaillet]

1. Yes, PATH env is already rather long $env:PATH.Length (3823)
2. This is already a VS PowerShell Command prompt. Not really sure what running command.exe to run a BAT file could possibly do to the environment of the parent shell...
3. It seems wrong that it's even trying to run that legacy bat file when the environment is ALREADY set up for the VC tools.

[MichalStrehovsky]

It seems wrong that it's even trying to run that legacy bat file when the environment is ALREADY set up for the VC tools.

We do this because people often have the wrong environment set up. When launching "Developer PowerShell for VS 2022" as found in the Start menu, the environment gets set up to target x86 (link.exe that is on PATH and the LIB environment variable all point to x86 binaries that are not usable for x64 targets). Trying to target win-x64 with that environment would result in bad failure modes. We re-run vcvarsall to obtain the correct toolset paths.

Looks like this is a case where vcvarsall can no longer run because it hits environment limits. I think this would be more actionable through Visual Studio channels: https://learn.microsoft.com/en-us/visualstudio/ide/how-to-report-a-problem-with-visual-studio?view=vs-2022 - we rely on a usable Visual Studio installation to target Windows.

[smaillet]

To be blunt - I don't care about the politics of finger pointing here. This ONLY happens with dotnet publish. No other commands have this problem. If the environment is configured incorrectly, then it should report such as an error that is reasonable and actionable by the user. As it stands the publish command is broken, very silently reporting issues that are not indicating the underlying problem nor anything actionable on the part of the user to resolve it. That's a problem with dotnet publish command. If that command uses something else that's not behaving as you'd hope then YOU need to get that fixed or find an alternative, so your tooling works correctly.

[MichalStrehovsky]

Looks like running vcvarsall in an already initialized environment is unsupported: https://developercommunity.microsoft.com/t/vcvarsallbat-reports-The-input-line-is/257260?q=vcvarsall+%22The+input+line+is+too+long.%22&fTime=allTime

I'll leave this open for tracking but don't see what we can do about this in the near term here.

[smaillet]

I'm confused. You say:

but don't see what we can do about this in the near term here

But the general solution seems obvious to me. Detect this condition and DON'T call that bat file if you don't need to. The problem in dotnet publish use here is that it is ALWAYS and blindly calling that assuming it will do the right thing. But it won't. Even for the stated goal of adjusting if the user has already done the wrong thing it can't reset the state of things (That's a bug on VC team). If there's no way to run the tool to fix the problem - then STOP! Generate an actionable error and bail out. The BUG for dotnet here is that it doesn't do that. The fix is to do that. Seems pretty obvious to me. If VC team ever fixes their tool, then it won't matter to dotnet.exe (or, more importantly, it's users).