[NETSDKE2E] With NET 9 RC2 SDK installed, running projects created with CLI result in unwanted strings

[vdtirlochan]

Build info:
9.0.100-rc.2.24428.4 (runtime-9.0.0-rc.2.24426.3)

Repro steps:

1. Download NET 9 RC2 SDK on win-x64
2. Create a console project with CLI
   dotnet new console
3. Build the console
   dotnet build
4. Run the console
   dotnet run

Expected:
Project runs successfully without any unwanted strings

Actual Result:
Unwanted strings are shown together with the output

dotnet --info
.NET SDK:
Version: 9.0.100-rc.2.24428.4
Commit: 0030622fd9
Workload version: 9.0.100-manifests.12008748
MSBuild version: 17.12.0-preview-24426-01+14df0589a

Runtime Environment:
OS Name: Windows
OS Version: 10.0.20348
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\9.0.100-rc.2.24428.4\

.NET workloads installed:
Configured to use loose manifests when installing new manifests.
There are no installed workloads to display.

Host:
Version: 9.0.0-rc.2.24426.3
Architecture: x64
Commit: static

.NET SDKs installed:
9.0.100-rc.2.24428.4 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.32 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.0-rc.2.24426.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.32 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.0-rc.2.24426.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 9.0.0-rc.2.24425.1 [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:
Not found

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

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

[baronfel]

This is terminal logger emitting to a console that doesn't support certain terminal capabilities. @rainersigwald we might have a gap here.

@darrenarvin123 what terminal are you using?

[v-ainigao]

This issue also appeared once in ARM64OS.
Environmental Information: .net9RC1 upgrade .net9RC2
step:

1. Install .net9RC1sdk
2. create a console in CLI, build and run
   dotnet new console
   dotnet build
   dotnet run
   3.upgrade .net9RC1sdk to .net9RC2
   4.Build and run the previous RC1 project
   

[vdtirlochan]

This is terminal logger emitting to a console that doesn't support certain terminal capabilities. @rainersigwald we might have a gap here.

@darrenarvin123 what terminal are you using?
Command Prompt

[baronfel]

I'm going to transfer this to the MSBuild repo.

[rainersigwald]

Hmm, the codes are mostly working though; look at all the overwriting and status type stuff here:

Screen.Recording.2024-08-29.094733.mp4

What is the flow here with the new dotnet run changes? Is the first build part doing a normal MSBuild invocation, then a second phase that news up a TL using the reflection in the SDK, right?

If so that's falling into a trap MSBuild appears to have set. We enable ANSI processing in our entrypoint

msbuild/src/MSBuild/XMake.cs

Line 2996 in b82694a

useTerminalLogger = CheckIfTerminalIsSupportedAndTryEnableAnsiColorCodes();

instead of in TL itself.

Given the cycle time would it be easier to fix this in SDK or MSBuild, @baronfel?

[baronfel]

We've got 3 weeks before SDK locks down, is that enough time to diagnose and fix in MSBuild? Great spot on the run interaction here!

[rainersigwald]

I would think so. @MichalPavlik?

[MichalPavlik]

I assigned this one to myself. Let's discuss details during our triage.

[richaverma1]

@rainersigwald any updates on this? Is this getting fixed for .NET 9 RC2?

[rainersigwald]

@richaverma1 Seems pretty unlikely for RC2--unless @MichalPavlik has a fix prepared I don't know about.

[MichalPavlik]

Working on multiple things right now, but I will prioritize this one.

[MichalPavlik]

PR was merged, so I'm closing this issue. Please reopen if needed.

[vdanche]

not repro on 9.0.100-rc.2.24470.13(runtime-9.0.0-rc.2.24463.7)

[vdanche]

@MichalPavlik so weird, today we met it again on net9 rc2 candidate build: 9.0.100-rc.2.24474.11 on EN Windows Server 2012 R2

but did not meet it on EN win11-x64 with same build

FYI @richaverma1

[MichalPavlik]

I think I know what is the root cause here. As the .NET 9 is already in RC stage, I did a minimal change to get rid of this behavior on consoles that supports VT100. Unfortunately, Console Host in Server 2012 doesn't support VT100. This implementation was added in Windows 10 1511 / Windows Server 2016 TP4.
My plan is to add more complex code to cover this scenario, but I'm not sure it could be part of .NET 9 GA. Windows Server 2012 is not officially supported anymore, so I believe the customer impact is not high enough to meet bar right now.

@baronfel , please correct me if you have different opinion.

[vdanche]

I think I know what is the root cause here. As the .NET 9 is already in RC stage, I did a minimal change to get rid of this behavior on consoles that supports VT100. Unfortunately, Console Host in Server 2012 doesn't support VT100. This implementation was added in Windows 10 1511 / Windows Server 2016 TP4. My plan is to add more complex code to cover this scenario, but I'm not sure it could be part of .NET 9 GA. Windows Server 2012 is not officially supported anymore, so I believe the customer impact is not high enough to meet bar right now.

@baronfel , please correct me if you have different opinion.

@MichalPavlik Currently it still repro on net9 rtm sdk on winserver2012 R2. Do we need to open a new bug for winserver2012 R2 or reopen this issue?

[richaverma1]

@vdanche file a new bug for winserver2012 R2 and mention this one in it.