terminal logger prevents output messages

[zivkan]

Describe the bug

The .NET 9 SDK appears to default to a "terminal logger". For normal builds I can see why some people would prefer this. However, it's preventing my custom target's output messages from being displayed at all.

To Reproduce

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net9.0</TargetFramework>
  </PropertyGroup>
  <Target Name="doTest">
    <Message
      Text="Test"
      Importance="High" />
  </Target>
</Project>

then run dotnet msbuild -t:doTest

Exceptions (if any)

No exception, but my Test message isn't displayed. I have to run dotnet msbuild -t:doTest -clp:off to see the message.

Further technical details

dotnet 9 SDK

[baronfel]

What about with -v diag?

[zivkan]

yes, it does display with -v:d. I thought the point of Importance="High" is that it should be shown even at quiet, or at least normal, verbosity? It's not even showing at normal, unless I disable the terminal logger.

[baronfel]

What is normal is relative to each logger. Normal for the console logger isn't normal for the terminal logger, where we've deliberately taken a more strict stance on output due to years of creeping use by authors.

[zivkan]

Maybe there need to be docs improvements, or I just didn't find the right docs? Feel free to close this issue though, if you think it's by design, or if it is documented, but I didn't find it, or if's an MSBuild issue that doesn't belong in the sdk repo.

MSBuild's docs on the Message task says:

Typically, a message set to high is sent when logger verbosity is set to LoggerVerbosity.Minimal or higher

That Typically word is doing a lot of heavy lifting here. If that word wasn't there, I'd call this a bug, by typically gives a technical out, even though it's not explaining why the .NET 9 SDK's default because differs from this "default" (or prior versions).

It not obvious to me that the output should change depending if I use -tl:off or not, at the same verbosity level. I'd expect the same output, and the Message task's docs don't (yet? after all .NET 9 is still in preview) say anything about .NET 9 treating importance differently than before.

[BretJohnson]

This is also a blocking issue for MAUI Hot Reload build tasks, where we use Message with Importance="High" to output build information that we expect to be visible to the end user, when they build in VS Code and command line. This is now broken in net9.

This does seem like a bug - the whole point of Message with High importance is show a message that the user can see, with default logging levels. But if this change was really by design (which seems unlikely IMO - seems more like an accidental bug, but IDK), then what do you expect folks to do instead in their projects / build tasks to output a message that shows up by default with the terminal logger? Thanks.

[ByronMayne]

Yeah this is annoying, it took me a while to figure out why I could not see my output from my build scripts. I did not even know what to google. Having to know that -tl:off is just invalidates the years of documentation about writing custom tasks in MSBuild.

[nkolev92]

cc @agr who is being affected by this trying to investigate networking issues.
This makes networking investigations for NuGet really hard, since NuGet logs HTTP requests on normal verbosity.

Right now even with --verbosity detailed you don't get them.
You need to know to turn off terminal logger to get this detailed output.

Feels like when --verbosity detailed is passed, tl should either be turned or implement to actually log a comparable amount of information that console logger did.

[abezverkov]

Going to throw in here. While I can understand the sentiment that over the years authors have abused the "High" importance leading to a general creep and possible overwhelm of output, there still needs to be a documented way to display a message on the output when the user is running the command in the terminal. If you need to add a "Very High" or any other documented solution. As it stands now, the because users are habituated to NOT adding a verbosity, is the only way I can update my pack to run with 9. And that comes with a load of extra baggage I dont want.

[McPherran]

#1 An appropriate courtesy for such a situation, is to display a message about the new state of affairs. I spent considerable time wondering why my Messages weren't displayed until I discovered this new behavior about Terminal Logger.

#2 I think that this feature likely has a bug anyway, because default -tl:auto doesn't work, yet -tl:off does. This indicates that either a.) "auto" is not detecting properly because it's not falling back to "off" behavior., or b.) "auto" sets "tl on" state, but the new tl messaging simply doesn't work for some or all environments.

#3 I'm using Windows Terminal with Intel 630 GPU. I have beautiful graphics in Windows Terminal, and I find it surprising that the new Terminal Logger feature doesn't work with Windows Terminal. Perhaps this is another bug with the feature.

I agree with the general sentiment here that the roll-out of this new feature is poorly performed. In editors/IDEs and other apps etc. one might tolerate a few preview-level features (generally optional anyway), but not build systems. I use build Messages to test/debug build properties.

Additional General Note:
I do understand and appreciate that .NET is an open-source and powerful platform, free of charge. However, I have concerns that the open-source world is non-ideal with regards to quality. I'm not presuming that the open-source aspect is a cause of this issue, however: Windows OS has reliable quality. If I install a Windows Update, I don't expect Event Logging (logs available in Event Viewer) to stop working, for example. One widely known concept that is related to "open source" is "free but not free as in price". Yet, where do we see Business Open-Source Software Licenses?? So, I suggest Business Open-Source Software licenses, whereby a small fee is paid. I'd happily return to payments for software (provided that they are small/reasonable), and perhaps many others share this posture. Thank You.

[monoman]

Please make it easy to turn this terminal logger off on dotnet.config.
It is VERY disturbing to see the messages flash and disappear before I can read...
As I use bash in windows probably I'll create an alias dbuild='dotnet build -tl:off ' to be able to see the needed messages...

[zivkan]

@monoman MSBuild supports something called a "response file". The name makes absolutely no sense to me at all, and I've never seen anything like it outside of Microsoft products, but anyway, but many Microsoft products support "response files", including MSBuild.

If you create a file named MSBuild.rsp, MSBuild should read it and append (or prepend?) it onto the current command line. In other words, if you make the contents of the file -tl:off, then dotnet build should in theory always use -tl:off automatically.