Skip to content
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

.NET 9 terminal logger litters output with "Build succeeded" on commands that do not build anything #44848

Open
plioi opened this issue Nov 13, 2024 · 1 comment
Labels
Area-NetSDK untriaged Request triage from a team member

Comments

@plioi
Copy link

plioi commented Nov 13, 2024

Describe the bug

After upgrading to the .NET 9 SDK, build scripts issuing dotnet commands litter the output with Build succeeded in X.Xs even for commands other than dotnet build.

To Reproduce

For an example, see build.ps1 in a representative repo at https://github.com/fixie/fixie/blob/ca6aac79f8a6dcec2b4abf58c537abca94a2b251/build.ps1

  • dotnet clean... is now followed by "Build succeeded in..." where it was not before.
  • dotnet $fixie... where $fixie is the path to a built dll, simply executing it, is now followed by TWO occurrences of "Build succeeded in..." where none were output before. I suspect this is because the first invocation is the one witnessed in the build script, and then the second is likely because the invoked executable itself is issuing a dotnet command to run a secondary dll in the same fashion via ProcessStartInfo.
  • dotnet pack... is now followed by "Build succeeded in..." where it was not before.

Proof that this output did not happen before can be seen in the Build section of this github actions job: https://github.com/fixie/fixie/actions/runs/11688386793/job/32548703947

This change to the output can only be confusing for non-build commands, and if we have to start littering all of our commands with something extra to suppress it by adjusting verbosity (and accidentally suppress substantive other details), then the phasing out of the explicit --tl was a net loss.

Further technical details

λ dotnet --info
.NET SDK:
 Version:           9.0.100
 Commit:            59db016f11
 Workload version:  9.0.100-manifests.c6f19616
 MSBuild version:   17.12.7+5b8665660

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19045
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\9.0.100\

.NET workloads installed:
 [aspire]
   Installation Source: VS 17.12.35506.116
   Manifest Version:    8.2.2/8.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.2.2\WorkloadManifest.json
   Install Type:              Msi

Configured to use loose manifests when installing new manifests.

Host:
  Version:      9.0.0
  Architecture: x64
  Commit:       9d5a6a9aa4
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-NetSDK untriaged Request triage from a team member labels Nov 13, 2024
@plioi
Copy link
Author

plioi commented Nov 13, 2024

The behavior is varying by environment. Here is a far simpler library where the behavior is as I described above when I run locally, but in github actions the behavior is correct. Both running .NET 9 SDK with confirmation in the Actions log using dotnet --info: https://github.com/fixie/fixie.assertions/actions/runs/11824888740/job/32947429874?pr=12

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-NetSDK untriaged Request triage from a team member
Projects
None yet
Development

No branches or pull requests

1 participant