Adding a static factory for the TerminalLogger

[MichalPavlik]

Fixes #10998

Context

Although I created the SDK hotfix to always use the ConsoleLogger, we want to use TerminalLogger when it's possible.

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 or CLI argument --tl:off.
This change also prevents emitting of progress indication when the verbosity is set to quiet.

Copilot reviewed 1 out of 1 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (2)

src/MSBuild/TerminalLogger/TerminalLogger.cs:1089

• [nitpick] The variable name 'tlArg' is ambiguous. It should be renamed to 'terminalLoggerArgument' for better readability.

string tlArg = args?.FirstOrDefault(a => a.StartsWith("--tl:", StringComparison.InvariantCultureIgnoreCase)) ?? string.Empty;

src/MSBuild/TerminalLogger/TerminalLogger.cs:1087

• Ensure that the new behavior introduced by the 'CreateTerminalOrConsoleLogger' method is covered by tests.

public static ILogger CreateTerminalOrConsoleLogger(LoggerVerbosity verbosity, string[]? args)

[MichalPavlik]

@baronfel, I know you would like to have full support for CLI logger configuration, but it will require some refactoring as the code for argument parsing is mostly placed in XMake. I wanted to break up XMake years ago, but now we have a valid reason to refactor at least part of the huge file :) If you don't mind, I would create a separate issue for this work.

[baronfel]

LGTM, but should we use this factory in our own codebase to dogfood?

[baronfel]

@baronfel, I know you would like to have full support for CLI logger configuration, but it will require some refactoring as the code for argument parsing is mostly placed in XMake. I wanted to break up XMake years ago, but now we have a valid reason to refactor at least part of the huge file :) If you don't mind, I would create a separate issue for this work.

Yeah, that is quite a large unit of work - makes sense to carve it out.

[MichalPavlik]

LGTM, but should we use this factory in our own codebase to dogfood?

I wanted to do it from the beginning, but the entry point logic emits global messages when it detects that TL couldn't be used. The easiest solution is to make the list of deferred messages in XMake internal, but I don't like it from an engineering point of view (separation of concerns, class coupling, etc.).

I think we could move the factory to some already public type like ConsoleLogger, so the CLI doesn't have to use reflection. Then we could move the list of deferred messages from XMake to the Logger class and use it directly in the factory or, in a cleaner way, return some indication of why the TL cannot be used and let XMake create the messages. Let's sync offline.

Edit: I'm looking at XMake once again, and actually, there are multiple things that make dogfooding the factory... problematic :(

[MichalPavlik]

We decided to reuse parameters parsing logic to support all CL and TL logger parameters in this case.

[MichalPavlik]

We agreed to use the factory as is and make it public. Support for all parameters will be added later.

[rainersigwald]

I'm not sure I see why "quiet" implies "don't make the spinner go", can you elaborate on that a bit?

[MichalPavlik]

Requested by @baronfel

[baronfel]

Exactly - users think of --quiet as --silent in other tools - meaning there should be no observable change at all if possible. In lieu of another explicit "don't do progress/spinners/etc" flag that should disable the spinner because it mangles the output.

[JanProvaznik]

this is different than creating Terminal logger in Xmake 😩 - there it recognizes "false" and "0" as well. (it's a bit silly part of Xmake)

msbuild/src/MSBuild/XMake.cs

Line 2966 in 072c659

string NormalizeIntoBooleanValues()

Also could this code live in Traits?

[MichalPavlik]

I'm probably blind, but the NormalizeIntoBooleanValues() is testing the variable for on and off values :)

I want to use Traits eventually, but there is a set of tasks that I want to resolve first.

• We need to place all our resources to single assembly
• Then we can get rid of shared sources from MSBuild and use InternalsVisibleTo without type conflicts
• Then we can move the CommandLineSwitches* to Microsoft.Build
• Then we can move the arg parsing logic from XMake to this project and invoke the factory from XMake

[JanProvaznik]

oops I meant to link the whole method processing tl args

msbuild/src/MSBuild/XMake.cs

Line 2826 in 072c659

private static bool ProcessTerminalLoggerConfiguration(CommandLineSwitches commandLineSwitches, out string aggregatedParameters)

, normalize is just one part of it

the logic is basically:

1. try getting -tl: value from console or from the env var
2. convert "on" to "true", "off" to "false"
3. parse a boolean from a string -> the actual info whether to use terminal logger

(at this point I am confused what it'll do for 0 and 1, but for true and false it'll definitely set the tl on or off)