sdk: [Bug]: getItem/getProperty output can contain unrelated junk

Issue Description

getItem/getProperty output can contain unrelated junk

Steps to Reproduce

$ mkdir getproptest && cd getproptest
$ dotnet new console
$ rm ~/.dotnet/*Sentinel
$ dotnet build /getProperty:OutputPath

Expected Behavior

bin\Debug/net8.0/

Actual Behavior

Welcome to .NET 8.0!
---------------------
SDK Version: 8.0.100-rc.2.23502.2

Telemetry
---------
The .NET tools collect usage data in order to help us improve your experience. It is collected by Microsoft and shared with the community. You can opt-out of telemetry by setting the DOTNET_CLI_TELEMETRY_OPTOUT environment variable to '1' or 'true' using your favorite shell.

Read more about .NET CLI Tools telemetry: https://aka.ms/dotnet-cli-telemetry

----------------
Installed an ASP.NET Core HTTPS development certificate.
To trust the certificate, run 'dotnet dev-certs https --trust'
Learn about HTTPS: https://aka.ms/dotnet-https

----------------
Write your first app: https://aka.ms/dotnet-hello-world
Find out what's new: https://aka.ms/dotnet-whats-new
Explore documentation: https://aka.ms/dotnet-docs
Report issues and find source on GitHub: https://github.com/dotnet/core
Use 'dotnet --help' to see available commands or visit: https://aka.ms/dotnet-cli
--------------------------------------------------------------------------------------
An issue was encountered verifying workloads. For more information, run "dotnet workload update".
bin\Debug/net8.0/

Analysis

I’ve also gotten the “Workload updates are available. Run dotnet workload list for more information.” message at the end in some cases (which I believe shows up once per day), and broke the json parsing I was trying to do.

Ideally getItem/getProperty arguments would take another argument specifying the output path, because relying on stdout not containing any other random junk is unreliable, and quite unsuitable for scripting.

Versions & Configurations

$ dotnet --version 8.0.100-rc.2.23502.2

About this issue

  • Original URL
  • State: open
  • Created 8 months ago
  • Comments: 25 (15 by maintainers)

Most upvoted comments

@jrdodds dotnet does have a verbosity flag that is generally used:

-v, --verbosity <LEVEL>              Set the MSBuild verbosity level. Allowed values are q[uiet], m[inimal], n[ormal],
                                       d[etailed], and diag[nostic].

and the q/quiet level is intended to represent silence. However, the first-run message and workload update message don’t use that for Reasons ™️. There are environment variables to control both the first-run message and the workload notification behavior:

I would suggest that folks who want to have a clean scripting experience set those to help ensure consistency until we can get the SDK to have more consistent output.

https://github.com/dotnet/msbuild/issues/3911 included a -resultsFile switch that didn’t make it into the code.

Yes, I’d track this as a change to the SDK (though the suggestion to write results to a specified file is also good). The SDK historically hasn’t been a good citizen with regards to polluting stdout, and we should make it better in that regard.