dotnet build ignores /v verbosity flag in .NET 9.0.0-preview.7
#43069
Comments
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
|
Do you have a repro project or some kind of logs to show a compare or contract? My best guess without any more information is that Terminal Logger (the default logger in .NET 9 for MSBuild) doesn't show the output you're used to. Try |
|
Sorry @baronfel, didn't have any public repro but I tested now with a blank I tested a few different approaches new:
|
|
To disable the terminal logger you need: If that gives you the missing output, then this is a dup of #42835. |
|
@perlun are you able to get the expected output by adding the |
|
Sorry for the late reply @tmds. Verified now - yes; Should we make I think my main point is that this (our current semantics) is a change from how it's been working in the past. I guess it could also be solved by documenting this in some relevant place(s), to make people more aware of it. |
|
I agree, setting the verbosity argument should be enough to enable verbose output. I assume the current behavior is an unintended UX regression from adopting the terminal logger. I would also hope this gets addressed in the 9.0.1xx SDK. Can we close this as a dup of #42835? |
|
One thing I'm unclear of is which specific lines you were expecting to see that -v diag in terminal logger didn't show. |
|
On a .NET 9 preview 7 gives: While .NET 8 prints out 57k lines. |
|
@tmds yes, I understand it doesn't show as much. That's the explicit design goal. Too much output is confusing to users, and we want to give a better idea of what's happening now, and guide users to binlogs for detailed investigations. We can tweak the behavior though, which is why I'm asking specifically: what kinds of output are missing from the default experiences that you would like to see? "everything" isn't a clear enough answer. |
I expect to see what matches that MSBuild verbosity level. Personally, when I use verbosity on any tool, I tend to set it high because I'm trying to get as much information as I can to debug an issue. Then I filter through what I got.
May be I should make more of an effort to embrace the x-plat MSBuild Structured Log Viewer... From the cli it should still remain possible to get verbose logging and use that to investigate without needing some IDE/GUI tool. |
It is :) if you need investigations, use the text logger and/or bin logger. For people like you that are very informed, I think binlogs would be even better since you can write tooling on top of them in a way that's impossible for the console logger. That's our answer right now. For the 80-90%+ users that aren't you though we want TL to give you the overview with a nice veneer of usability. We definitely need to update the CLI argument descriptions to highlight that these values are relative per-logger, though.
Also yes, you 100% should try this out. It makes all kinds of MSbuild analysis so much easier and faster. |
|
My preferred behavior would be to turn of the terminal logger when a verbosity argument is set. I think this matches the use-case: user is debugging their build. It seems the current behavior is intentional, so we can close this issue (and #42835). |
Intentional it is indeed, but it's still a nasty regression. 😛 We already have people like me and @MarcoRossignoli who posted these issues, and it's likely that more people will run into this as .NET 9 goes live. At the very least, we should make this very significant change in how As for your question @baronfel:
IIRC, I was debugging an issue where I was setting MSBuild constants dynamically based on conditions. I wanted to see things like what values It's fine to suggest binlogs and such, but it still seems to be a bit more work than just |
@lambdageek has got a present for you: https://marketplace.visualstudio.com/items?itemName=lambdageek.msbuild-structured-log-viewer |
|
I have reports that are generated by MSBuild with -v:n and the It appears there is no control of the verbosity of TL with respect to the Is there a way for a project to indicate it is not compatible with TL? I expect that the answers are no, yes, and no, respectively. |
Are there other binlog tools available or coming? Other than Kirill Osenkov's structured log viewer and the VSCode extension based on it? |
nagilson
added
needs team triage
|
Back in dotnet/msbuild#9810 we added writing of High-verbosity messages to the Terminal Logger when the verbosity of the Terminal Logger is set to detailed or diagnostic. In dotnet/msbuild#10859 we're working to codify the behavior and use cases for each logger (to eventually also get this content into MS Learn docs) - today you can trigger this increased output by using |
|
Triage: Per baronfel's comment, I'm going to close out this issue as high verbosity messages have been added to TL. Any additional improvements you're looking for you can comment on the msbuild issue or file a new issue over there as TL is controlled by MSBuild. |
Describe the bug
dotnet buildignores/vverbosity flag in .NET 9.0.0-preview.7To Reproduce
Run
dotnet build SomeProject.sln /v:dOn .NET 8 (by temporarily downgrading the
dotnet-hostpackage usingapt-get install dotnet-host=8.0.8-1), this correctly increases the verbosity level tod[etailed]. On .NET 9, the setting seems to be ignored. The output is seemingly the same as inn[ormal]mode.Adding the
--debugflag also has no effect, on .NET 9.Exceptions (if any)
None
Further technical details
dotnet --info:Seen on both Windows (11?) and Debian GNU/Linux (my machine). Output for the latter from below:
dotnetCLI.The text was updated successfully, but these errors were encountered: