`dotnet` should report .NET not MSBuild version

[richlander]

Proposed:

$ dotnet build
.NET SDK 8.0.100 (preview; linux-x64; 57efcf1350)
  Determining projects to restore...
  All projects are up-to-date for restore.
  app -> /home/rich/app/bin/Debug/net8.0/app.dll
$ dotnet --info
.NET SDK:
 Version:           8.0.100
 Commit:            57efcf1350
 Workload version:  8.0.100-manifests.2d90560f
 MSBuild: 17.8.3+195e7f5a3
 NuGet: 6.8.0.32767

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  23.10
 OS Platform: Linux
 RID:         ubuntu.23.10-x64
 Base Path:   /usr/lib/dotnet/sdk/8.0.100/

.NET workloads installed:
 Workload version: 8.0.100-manifests.2d90560f
There are no installed workloads to display.

Host:
  Version:      8.0.0
  Architecture: x64
  Commit:       5535e31a71

.NET SDKs installed:
  8.0.100 [/usr/lib/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.0 [/usr/lib/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 8.0.0 [/usr/lib/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

Existing:

$ dotnet build
MSBuild version 17.8.3+195e7f5a3 for .NET
  Determining projects to restore...
  All projects are up-to-date for restore.
  app -> /home/rich/app/bin/Debug/net8.0/app.dll

There are four key ideas there:

• Switch to reporting .NET version instead of MSBuild version (which is confusing/not useful).
• Add some variation of "preview" or "pre-release" to that same static line; we don't need to use MSBuild for that.
• Optionally add some more useful information to that same line so that people reporting issues naturally share more information to aid diagnosis.
• Move MSBuild information to dotnet --info and consider adding additional versions there, like NuGet.

Provides a solution for #34526.

@baronfel @jaredpar @aortiz-msft

[baronfel]

In broad agreement here, with the exception that I'm not sure we even need to echo the SDK version in build et al. I know @rainersigwald loves having that at-a-glance but realisitically binlogs and/or an improved dotnet --info output would cover that too.

There's an ongoing discussion about revamping --info (including potentially making it info instead) and giving it a more structured output that we can and should do.

[richlander]

I'm fine w/getting rid of the version entirely as long as that includes getting rid of the Preview message.

[KalleOlaviNiemitalo]

Please keep some way to output the MSBuild commit ID abbreviation. dotnet msbuild -version would suffice.

[rainersigwald]

I know @rainersigwald loves having that at-a-glance but realisitically binlogs and/or an improved dotnet --info output would cover that too.

A surprising number of build problems can be quickly chased down with this info, but if the CLI started passing -nologo I'd be fine with it.

Please keep some way to output the MSBuild commit ID abbreviation. dotnet msbuild -version would suffice.

Note that if the CLI unconditionally passed -nologo this would no longer have the commit ID, because the plain text output of -version is (for historical compatibility) the 4-part version rather than a semver string.

[Forgind]

A surprising number of build problems can be quickly chased down with this info

I very much agree with this statement. Additionally, I start with the assumption that if something is broken, the average user will show us that it's broken (screenshot or copying output) without running any extra commands even if the template asks them to. Including the MSBuild (or full SDK version) would then help us figure out how to reproduce their problem if it turns out to be a recent regression. baronfel's PR looks correct if the goal is just to remove that information from build and add some information to --info, but that seems like it would impede our ability to investigate bugs quickly as well as opening developers up to "oops; forgot I had a global.json" mistakes.

[baronfel]

The proper way to chase down global.json problems is dotnet --info, which tells you precisely where the file is.

[richlander]

I think special casing the MSBuild version doesn't make much sense. It's not at all clear that this is the verison # that the majority of users care about. Clearly, as the proposal suggests, we've still need to provide that information, via dotnet --info, as Chet suggests.

OK. Here's a proposal:

• Remove the MSBuild version string (aka --nologo).
• Remove the preview message/warning.

[KalleOlaviNiemitalo]

Remove the MSBuild version string (aka --nologo).

I feel dotnet msbuild should have the same defaults as msbuild.exe in this respect, even if you remove the MSBuild version output from dotnet build and dotnet clean.

[baronfel]

excellent point @KalleOlaviNiemitalo! re: the preview warning @richlander, @rainersigwald has added some handling in the terminal logger in dotnet/msbuild#9610 to de-duplicate so that there's only one warning. We could see what the response is to that, given that Terminal Logger will be the default in the .NET 9 previews.

[Forgind]

The proper way to chase down global.json problems is dotnet --info, which tells you precisely where the file is.

This argument applies, in some sense, to a lot of possible problems. I might argue that there's no reason we should log anything to the console at all—after all, you can get all that information out of a standard text log. Same for binlogs—they're just more structured forms of the same information as text logs. What I'm getting at is that we should try to log things if and only if we think it might help the user, and having a global.json somewhere above you is something you might not realize that would affect your build, and having a version of some kind there would help both the user and us (if they submit a bug). You're right that dotnet --info would get them that information, but will that be their first reaction to a build failure?

[richlander]

There are many reasons why a build can fail. Most of the time, builds fail for reasons unrelated to dotnet --info. I also think that there is a minimum bar for using any tool. For example, I sometimes consult docker version (which is the equivalent of dotnet --info). Funny, docker --version is the equivalent of dotnet --version.