Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
darrenarvin123 opened this issue Aug 29, 2024 · 11 comments · Fixed by #10678
Assignees
Labels

Comments

@darrenarvin123
Copy link

darrenarvin123 commented Aug 29, 2024

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
image

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

@darrenarvin123 darrenarvin123 changed the title [NETSDKE2E] With NET 9RC2 SDK installed, projects created with CLI result in unwanted strings [NETSDKE2E] With NET 9 RC2 SDK installed, running projects created with CLI result in unwanted strings Aug 29, 2024
@dotnet dotnet deleted a comment Aug 29, 2024
@baronfel
Copy link
Member

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
Copy link

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
    image

@darrenarvin123
Copy link
Author

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
Copy link
Member

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

@baronfel baronfel transferred this issue from dotnet/sdk Aug 29, 2024
@rainersigwald
Copy link
Member

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

useTerminalLogger = CheckIfTerminalIsSupportedAndTryEnableAnsiColorCodes();

instead of in TL itself.

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

@baronfel
Copy link
Member

baronfel commented Aug 29, 2024

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
Copy link
Member

I would think so. @MichalPavlik?

@MichalPavlik
Copy link
Member

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

@AR-May AR-May added triaged and removed untriaged labels Sep 4, 2024
@richaverma1
Copy link

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

@rainersigwald
Copy link
Member

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

@MichalPavlik
Copy link
Member

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

rainersigwald pushed a commit that referenced this issue Sep 19, 2024
…reated directly (#10678)

Call method that tells Windows to allow VT-100 output processing whenever the TerminalLogger is instantiated, rather than only in the MSBuild CLI entrypoint `xmake.cs`.

Fixes #10579.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants
@baronfel @rainersigwald @MichalPavlik @richaverma1 @AR-May @v-ainigao @darrenarvin123 and others