-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Weird progress indicators started appearing in stdout #10998
Comments
This issue talks about some new console logger in .Net9 I still see these characters in the output file if build and run are done in separate steps:
And it happens in both Command Prompt and Powershell terminal |
This seems to be coming from how
But surprisingly, setting Actually, |
The forced TerminalLogger came from dotnet/sdk#42240. I think |
@KalleOlaviNiemitalo thanks for the investigation :) Seems like this has been raised before and we'll have to live with this for some time after GA :( |
That is for older versions of Windows that don't recognise the control sequences. I assume the fix would be to check the version number. That won't help with redirection. The fix #10678 makes MSBuild configure the Windows console to process control sequences if TerminalLogger is used directly, and restore the original modes later. This also doesn't help with redirected output, where MSBuild should not write the control sequences at all. Although the code checks whether output is redirected, and does not configure the console in that case, it writes the control sequences anyway. |
A low-risk fix would be to make dotnet-run check whether output has been redirected, and not add the TerminalLogger in that case; instead add a console logger that is configured to output only errors and warnings, and those to stderr rather than stdout. In the longer term, I hope dotnet-run can let MSBuild create the logger objects (based on command-line options, environment variables, and redirection), and then use the same objects across restore/build/run. |
@baronfel is MSBuild planning on some updates here? |
This also currently breaks .NET custom providers in pulumi:
Workaround: |
We have a host application, running .net programs. For easier debugging we do the following:
And of course those programs are using the console to exchange data with the host. So when upgrading to net 9, happily writing escape codes in the console without any switch to disable this new behavior, everything is broken. 💔 Where we can spot the effect of: cc @baronfel |
^cc @MichalPavlik It's a real breaker for a lot of scenarios, unfortunately. (like azdo/github workflow output when |
.NET 9.0 introduced a bug where the output from `dotnet run` can include a progress indicator, even though the output is redirected: https://github.com/dotnet/sdk/issues/44610 This causes .NET plugins to fail when running under .NET 9.0 because we can't parse the port number. As a workaround, we strip these control characters.
.NET 9.0 introduced a bug where the output from `dotnet run` can include a progress indicator, even though the output is redirected: https://github.com/dotnet/sdk/issues/44610 This causes .NET plugins to fail when running under .NET 9.0 because we can't parse the port number. As a workaround, we strip these control characters.
Indeed, we just ran into this when trying to add tests for .NET 9.0 in Pulumi's CI. As a workaround we'll strip the control characters pulumi/pulumi#17783 I'd love to see an upstream fix for this in the next release. |
.NET 9.0 introduced a bug where the output from `dotnet run` can include a progress indicator, even though the output is redirected: https://github.com/dotnet/sdk/issues/44610 This causes .NET plugins to fail when running under .NET 9.0 because we can't parse the port number. As a workaround, we strip these control characters. This PR also tightens the port parsing to handle invalid numbers. Previously these would error in the `dialPlugin` done just after parsing the port.
This will happen when using |
|
@sailro, that's right. I'm working on a fix that additionally respects the |
@MichalPavlik some context: There are up to three builds that happen during
The purpose of the third build is to be completely invisible unless there are diagnostics reported from the third build. The third build's console logger setup should ideally be exactly matched to that of the first two builds, but the CLI doesn't know what MSBuild's logging argument configuration is to attempt to recreate it via the API. This is a long-running disjoint/mismatch between MSBuild and the CLI because MSBuild doesn't expose any knowledge about its argument parsing, but it's a particular pain point here for this use case. So there are two requests here I think,:
|
There might also be something fixable on whether those control sequences are emitted to standard output or standard error. |
To me, additional confusion comes from this document: https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotnet-9/sdk#terminal-logger
TBH I thought we'd given up spraying VT100 escape codes into output in the 1990s, I'm not sure why we have to go through this again. |
Why have I started seeing the following character sequence (which seems to some progress indicator) whenever I pipe dotnet program output to a file now?
\x1b]9;4;3;\x1b\\\x1b]9;4;0;\x1b\\
Program.cs:
dotnet run > output.txt
output.txt:
The text was updated successfully, but these errors were encountered: