Add "Who built this" to `dotnet --info`

[richlander]

We're lucky to have so many organizations building .NET. However, it can be difficult to tell which build you are using. For example, it's possible on Linux to install .NET from Microsoft or from the distro and both are valid choices.

I'm thinking about something like this (see last line).

$ dotnet --info
.NET SDK:
 Version:           8.0.100
 Commit:            57efcf1350
 Workload version:  8.0.100-manifests.2d90560f

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
  Built by: Microsoft

By default, that value would be blank. The downside of this idea is that it would be easy for someone with malicious intent to say "Microsoft" for this value to trick people (and get them to run their code). I'd suggest that it is already possible to do same (in DLL resources) and by the time dotnet --info runs then the gig is already up.

[richlander]

@omajid

[baronfel]

One key piece of information we should add is a very clear marker of this current host/SDK is coming from an extracted tarball vs a package-based install. Over this last holiday break alone I saw a number of error reports from folks that had mixed tarball and package-based installs and so weren't having success using our tooling, and every time there was a back and forth of discovering that the user has at one point corrupted their local environment with a tarball + PATH modification.

[richlander]

How would we know that?

[baronfel]

The SDK at least has an installtype that can help direct the discovery, but we could also have a heuristic based on 'is the current host/SDK installed under the documented install locations or not' and then reuse the /etc/dotnet/install_location scheme (and registry lookup on Windows) to help answer that question. Or we could make up a new thing fit for purpose and flow that through. We just need something to make the situation user-triagable because it's a mess right now.

[richlander]

I like the /etc/dotnet/install_location idea. It's way too easy to unpack a tarball to the documented install location. That's what we do for containers and I often do that on my machine.

[baronfel]

@dsplaisted do we have anything like the workload installType in the SDK payload at the moment? If not, should we?

[omajid]

I have no concerns about adding more details to dotnet --info (or other commands) to show more details about the builder. I agree that it would make it easier to diagnose certain type of issues.

For examples of prior art, on Fedora, several programs show Fedora/Red Hat as the vendor/builder:

$ clang --version
clang version 17.0.6 (Fedora 17.0.6-1.fc39)
Target: x86_64-redhat-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

$ gcc --version
gcc (GCC) 13.2.1 20231205 (Red Hat 13.2.1-6)
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ java -version
openjdk version "17.0.9" 2023-10-17
OpenJDK Runtime Environment (Red_Hat-17.0.9.0.9-4) (build 17.0.9+9)
OpenJDK 64-Bit Server VM (Red_Hat-17.0.9.0.9-4) (build 17.0.9+9, mixed mode, sharing)

$ java -XshowSettings:properties -version 2>&1 | grep 'vendor'
    java.specification.vendor = Oracle Corporation
    java.vendor = Red Hat, Inc.
    java.vendor.url = https://www.redhat.com/
    java.vendor.url.bug = https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=java-17-openjdk&version=38
    java.vendor.version = (Red_Hat-17.0.9.0.9-4)
    java.vm.specification.vendor = Oracle Corporation
    java.vm.vendor = Red Hat, Inc.

$ python -VV
Python 3.12.1 (main, Dec 18 2023, 00:00:00) [GCC 13.2.1 20231205 (Red Hat 13.2.1-6)]

[richlander]

Cool! That helps.

[dsplaisted]

@dsplaisted do we have anything like the workload installType in the SDK payload at the moment? If not, should we?

I don't think we have anything else. It seems like maybe these should be the same thing - the install type for workloads should (I think) be the same as the install type for the SDK itself. Right now we only differentiate between file based and MSI, but we could add more options.

[ViktorHofer]

FWIW a switch for this already exists in dotnet/sdk to enable telemetry: OfficialBuilder

[richlander]

I think that does something different. That basically means "Microsoft". We need something that can result in "Red Hat", "Canonical", "Alpine Linux, ... .

[ViktorHofer]

Yes, I was just pointing out that we could pass that property in when building the VMR from source and it would get embedded into dotnet --info and be used for the sdk telemetry condition. Example: build.sh /p:OfficialBuilder="Red Hat".

cc @mmitche as this relates to one of the controls in your doc.