-
Notifications
You must be signed in to change notification settings - Fork 1.1k
[release/9.0.2xx] Use the static factory for creating a logger #45009
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
base: release/9.0.2xx
Are you sure you want to change the base?
Conversation
This should not be merged until dotnet/msbuild#11016 is flown in |
I think some test for |
As discussed offline, we have time for 9.0.200, so I'll convert this PR to draft and extend the MSBuild part. |
9.0.2xx is out of support now if I read https://learn.microsoft.com/en-gb/dotnet/core/porting/versioning-sdk-msbuild-vs#supported-net-versions correctly. Should this PR be closed? |
and/or re-targeted to 10.x, yeah probably. |
Fixes dotnet/msbuild#10998
Summary
dotnet run
directly creates an instance ofTerminalLogger
, bypassing all checks. This can lead to situations where ANSI escape sequences are emitted to the terminal, even if the terminal does not support them. These escape sequences are also emitted when the standard output is redirected, which can break a CI build that relies on the command's output.Changes Made
Added a static factory that can return instance of Terminal or Console logger based on current environment. The usage of
TerminalLogger
in this scenario can be explicitly disabled by using of already existing env. variable, which wasn't possible before.This SDK update uses this factory to pass the appropriate logger to MSBuild.
Customer Impact
Some customers reported unexpected behavior of
dotnet run
command and CI builds failures.Regression?
Yes.
Testing
Manual testing with locally updated SDK.
Notes
This PR depends on dotnet/msbuild#11016. Until the MSBuild PR is merged and inserted, this fix will not work.