dotnet build: Adding -tl:off prevents file-based app detection; breaks with spurious warning and MSBuild error

[kzu]

Describe the bug

When building a C# file-based app with dotnet build <file>.cs, it works. Adding a terminal logger CLI argument (like -tl:off) causes the CLI to treat it as a non-file-based input and falls through to MSBuild, showing a warning and then a project parse error.

Steps to reproduce

1. Create 'copilot.cs' as a file-based app.
2. Run dotnet build copilot.cs --target=Echo (works)
3. Run dotnet build copilot.cs --target=Echo -tl:off (fails)

Expected behavior

Adding terminal logger args should not interfere with file-based build detection. copilot.cs should be built as a file-based app.

Actual behavior

The CLI outputs a warning and then MSBuild emits an error about the C# file not being valid XML:

'copilot.cs' appears to be a file-based app but was treated as an MSBuild argument. To treat it as a file-based app, use 'dotnet build copilot.cs'.
error MSB4025: The project file could not be loaded.

Is this a regression?

Not sure. Reproducible with 10.0.300. Possibly affects all .NET 10 SDKs with file-based app support.

Are there any workarounds?

Set env var: $env:MSBUILD_TERMINAL_LOGGER = "off" (pwsh) or MSBUILD_TERMINAL_LOGGER=off .... Pipe to file. Don't use -tl:off.

dotnet --info output

.NET SDK:
 Version:           10.0.300
 Commit:            caa81fa497
 Workload version:  10.0.300-manifests.e0989437
 MSBuild version:   18.6.3+caa81fa49

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.26200
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\10.0.300\

.NET workloads installed:
There are no installed workloads to display.
Configured to use workload sets when installing new manifests.
No workload sets are installed. Run "dotnet workload restore" to install a workload set.

Host:
  Version:      10.0.8
  Architecture: x64
  Commit:       94ea82652c

.NET SDKs installed:
  8.0.421 [C:\Program Files\dotnet\sdk]
  10.0.300 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.27 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.16 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 10.0.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 8.0.27 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.16 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 10.0.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 8.0.27 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.16 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 10.0.8 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

global.json file:
  C:\Code\oss\sdk\global.json

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

IDE version

No response

Other details

Root cause and full analysis in main issue description. Likely fix: filter terminal logger args before file-based app arg check, consistent with binlog filtering.

[baronfel]

@dotnet/run-file MSBuild now exposes an API for parsing all of its command-line parameters - to nip this category of issue in the bud we should use it and then grab the first un-recognized argument after that parsing for the "thing that may be a file-based app name"

[jjonescz]

MSBuild now exposes an API for parsing all of its command-line parameters

Hm, but what would we do with the arguments like -tl:off - just ignore them? We are not invoking MSBuild command-line at all when building file-based apps. Hence we would need also some MSBuild API that can apply the parsed command-line arguments to the object model, but I don't imagine that exists.

[baronfel]

The intent would be that you could use this to 'remove' the entire category of "tokens that MSBuild understands that we want to reject for purposes of FBA detection", that way we're not coming back to this problem many releases from now as well.

Actually applying the command line wouldn't always be necessary - maybe only Property flags would be all that's required? But even that seems like a separate concert/unit of work to me.

[jjonescz]

But we are already rejecting those tokens. I don't think we should silently ignore them. For example, -tl:off should probably be handled by run-file and if it was just ignored, users would be confused. I guess we could use the parser to (1) implement the parsing when we want to handle the switches and (2) improve the error experience for unhandled switches. But we already recently improved the errors you get in these cases: #53833, this issue already shows it actually:

'copilot.cs' appears to be a file-based app but was treated as an MSBuild argument. To treat it as a file-based app, use 'dotnet build copilot.cs'.
error MSB4025: The project file could not be loaded.

I guess we could improve the wording to say also something like "'-tl:off' was an unrecognized argument; remove it to build as file-based app."

[jjonescz]

I guess we could use the parser to (1) implement the parsing when we want to handle the switches and (2) improve the error experience for unhandled switches

It doesn't look like the API is going to help us much for these scenarios either - if we still want to report errors for switches that are not supported by file-based apps.