Some way to opt specific messages into printing in TerminalLogger

[rainersigwald]

TerminalLogger ignores most messages, even those logged at High priority, because historically those messages have been quite chatty. But sometimes they're important--for instance, the output of test runners in dotnet/runtime#97211.

It'd be helpful if we either don't try to bypass priority (unfortunate since it'll make real build console output dramatically uglier) or provide a new mechanism for like "I really mean it please put this on the console output".

Right now it can be worked around if you're willing to junk up your high-pri message with the string --interactive, to trip into the special cases in #9407.

[baronfel]

Putting thoughts here for posterity, but many high-pri messages are status/progress - if we have an API for representing this concept specifically then the need for high priority messages may drop.

[rainersigwald]

The need for high pri messages, or the need to squelch them because Rainer thinks they're too chatty? For the case I'm looking at now they want persistent output (test output from a custom runner).

Of course, if most of the existing high-pri messages were status instead (per-project NuGet restore, exec task command lines and stdout, etc) we could respect priority again . . .

[MattKotsenas]

Another sample of a somewhat surprising omission in the TerminalLogger are NuGet.Client rules.

You can set up a trivial repro like this:

mkdir temp && cd temp && dotnet new classlib && dotnet pack

You'll see a console message like this

The package temp.1.0.0 is missing a readme. Go to https://aka.ms/nuget/authoring-best-practices/readme to learn why p
  ackage readmes are important.

That message is suppressed when using dotnet pack /tl.

These feel like they instead should be NU**** build warnings and then the "right thing" should happen, but I'm not familiar with the NuGet pack rules and how they work.

[baronfel]

The specific scenario of test results should not be considered for this issue - the test team have already been working on updating their usage of the Logger systems to display better in terminal logger: #9706

[rainersigwald]

The specific scenario of test results should not be considered for this issue

I don't agree--the fixes we're pursuing with the test team are great and I prefer them to whatever we come up with here, but there are other test runners (including custom one-off ones like dotnet/runtime has) and they should be able to work too.

[JanKrivanek]

One another scenario is users debugging their msbuild script with 'printf debugging'.
I already got some internal and external ppl comming with 'are there incrementality changes?' or 'Are there verbosity changes?' questions caused by this

They put <Message Text="executed" Importance="high" />, see that in output - all is fine. Then they run into similar need when on 9.x - see no results, switch to 8.x, see the result and suspect 9.x logging or incrementality issue. This can lead to wasted time with discovering the behavior and frustration

[JanKrivanek]

IIRC at some point we considered limited space (rollover) per project for high-pri messages. Is this completely out of question now?

I'm worried the Importance="high" is more spread knowledge in community now, than the knowledge of binlog viewer and this will catch many users off guard.