dotnet --info

[Petermarcu]

Steps to reproduce

type dotnet --info with no SDK installed.

Expected behavior

To get the version information about the .NET Runtime

Actual behavior

I get

Microsoft .NET Core Shared Framework Host

  Version  : 2.1.0-preview1-26001-02
  Build    : ac9a99009bb94ab9a57501da549d3d0058ca9300

I'm not sure how this is useful. The version is good as long as the host and runtime are always in lockstep but I'm pretty sure people are looking for the runtime version here. Do we need a --version switch on the host?

Environment data

[steveharter]

Yes the host information (actually hostfxr.dll, not dotnet.exe) is usually not that important as we always pick the latest. We could just remove it.

However, listing the available runtimes and sdks, like --list-runtimes and --list-sdks would be useful, as well as a URL to install additional runtimes and sdks.

How about this (shown how it would appear without SDK, or if an SDK is selected, after that information)

Microsoft .NET Core Shared Framework Host
  Version  : 2.1.0-preview2-26129-0
  Build    : 5c7b2d33e76ee8052a6941a090fcd21252ce2ea8

The following .NET Core SDKs are installed:
  No SDKs were found.

The following .NET Core runtimes are installed:
  Microsoft.AspNetCore.All 1.0.1 [C:\Program Files\dotnet\shared]
  Microsoft.NETCore.App 2.0.4 [C:\Program Files\dotnet\shared]
  Microsoft.NETCore.App 2.0.5 [C:\Program Files\dotnet\shared]
  Microsoft.NETCore.App 2.1.0 [C:\Program Files\dotnet\shared]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

p.s. I just added that aka.ms download link. I'll remove it if we don't go with it.

[steveharter]

@KathleenDollard PTAL. Thanks

[KathleenDollard]

Working on the SDK installed version was on my urgent list.

I love this.

If SDK's are installed, can you tell me what that will look like?

You have "ASPNETCore.All" which I assume is the new metapackage. Do you know who is involved with versioning that 1.0.1 (if that is from preview)?

Do you feel attached to the text of the host? I think this text is just confusing to programmers. Do we have sufficient linkage between the host and the default (no global.json) runtime that we could use a label that identified this as the default runtime?

I love that we will be able to list installed runtimes!!!

[steveharter]

You have "ASPNETCore.All" which I assume is the new metapackage. Do you know who is involved with versioning that 1.0.1 (if that is from preview)?

I am not sure what the released name and version of the ASP metapackage(s) will be. ASPNETCore.All is an existing metapackage that was used during prototyping of the multi-layer framework feature. I believe they plan on having two additional layers \ metapackages - one for internal assemblies, and another for external dependencies and thus may not even use ASPNETCore.All. cc @natemcmaster @davidfowl

Do you feel attached to the text of the host? I think this text is just confusing to programmers. Do we have sufficient linkage between the host and the default (no global.json) runtime that we could use a label that identified this as the default runtime?

I just left the "host" text as-is. That "host" version is just the hostfxr.dll (which sits in-between dotnet.exe and the runtime's hostpolicy.dll), and there is no guarantee of a 1:1 between that version and the runtime's version. Also note that the runtime selection is not affected by global.json, only the SDK selection.

Also there is really no such thing as a "default runtime". In order to get the version of the runtime that will be used, we need to know the app (the myapp.dll), since the app's runtimeconfig.json determines which runtime to select. We could add a new option something like this: dotnet --runtime-version myapp.dll which would not require the SDK.

Here's a help example with some SDKs installed:

Product Information:
 Version:            2.1.100-preview-007326
 Commit SHA-1 hash:  0ca4e2c47b

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.16299
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.100-preview-007326\

Microsoft .NET Core Shared Framework Host
  Version  : 2.1.0-preview2-26129-0
  Build    : 5c7b2d33e76ee8052a6941a090fcd21252ce2ea8

The following .NET Core SDKs are installed:
  2.1.100-preview-007326 [C:\Program Files\dotnet\sdk]
  2.1.4 [C:\Program Files\dotnet\sdk]

The following .NET Core runtimes are installed:
  Microsoft.AspNetCore.All 1.0.1 [C:\Program Files\dotnet\shared]
  Microsoft.NETCore.App 2.0.4 [C:\Program Files\dotnet\shared]
  Microsoft.NETCore.App 2.0.5 [C:\Program Files\dotnet\shared]
  Microsoft.NETCore.App 2.1.0 [C:\Program Files\dotnet\shared]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

IMO the "Product Information" on the top is somewhat vague; perhaps it should say "SDK Information"

[natemcmaster]

... released name and version of the ASP metapackage(s) will be.

Starting in ASP.NET Core 2.1.0-preview1, we plan to have two shared frameworks.

• Microsoft.AspNetCore.App
• Microsoft.AspNetCore.All

.All depends on .App.
.App depends on Microsoft.NETCore.App

[KathleenDollard]

@steveharter Could you sort these both here and in --list-runtimes and --list-sdks?

[KathleenDollard]

@steveharter

What does "Product Version" mean here?

Base Path here (the only thing we know people are using) does not reflect global.json, correct?

Why do we have both builds and hashes here?

Does info always come from the host, not the SDK?

[KathleenDollard]

@natemcmaster

I'm hoping we won't fall back into a 1.0 series as I think that would be quite confusing.

[KathleenDollard]

@steveharter

I'm struggling for a better suggestion for "Microsoft .NET Core Shared Framework Host"

I believe the only word there that contributes to meaning is the word "Host". I understand this to be important for support, and since it might not be the same as the runtime, I don't want to remove it and undermine support in that weird situation.

But the current name is confusing. I wonder if shortening it to just

dotnet Host
Version : 2.1.0-preview2-26129-0
Build : 5c7b2d3

would make things better or worse.

[natemcmaster]

Would nesting help make the list more readable?

The following .NET Core runtimes are installed:
  Microsoft.AspNetCore.All [C:\Program Files\dotnet\shared]
    - 2.1.0-preview1 
  Microsoft.AspNetCore.App [C:\Program Files\dotnet\shared]
    - 2.1.0-preview1
  Microsoft.NETCore.App [C:\Program Files\dotnet\shared]
    - 2.0.4 
    - 2.0.5 
    - 2.1.0-preview1

[davidfowl]

Part of me thinks this shouldn't be part of --info but I can see the appeal because it's easier. Ideally we'd have CRUD commands for manipulating both runtime and SDK. dotnet sdk list etc (DNVM esque)

[steveharter]

@KathleenDollard

Could you sort these both here and in --list-runtimes and --list-sdks?

Sort in what way? Alphabetically? Currently they are just taken from raw directory-read commands, so yeah that might not be sorted alphabetically all the time. Also Nate proposed a different way to sort

What does "Product Version" mean here?

It's "SDK Version"

Base Path here (the only thing we know people are using) does not reflect global.json, correct?

Base Path will show no matter if there's a global.json or not. If global.json exists, the SDK version there should match the version in Base Path.

Why do we have both builds and hashes here?

I'm not sure on the relevance of hashes here.

Does info always come from the host, not the SDK?

The information above Microsoft .NET Core Shared Framework Host comes from the SDK, the rest comes from the host. E.g. here's the SDK code section: https://github.com/dotnet/cli/blob/a212d5a0176f85e5aba9b117b1b408c5b60ee525/src/dotnet/Program.cs#L261

[steveharter]

@natemcmaster

Would nesting help make the list more readable?

I'm open for changing that for --info however what I have is the same format as what --list-runtimes and --list-sdks uses, which is easy to parse by tools so I don't want to change that (to require a multi-level parsing algorithm). So I guess keeping them the same for consistency has merits.

[KathleenDollard]

I'm going to vote against nesting. I think if we just sort alphabetically they are going to come out in a sane order and be easy to visually parse. I don't think this iteration of --info is going to be perfect or the last, we just need it to suck less and reflect the new version numbers decently.

I'm still confused by the SDK and base path. Maybe someone on the SDK is going to have to answer how global.json

Edit: On global.json: I ran the tests and they are reflected in my most recent cli comments.

[KathleenDollard]

This issue is associated with a similar issue in dotnet/cli

Both remain as probably work will occur in both repos.

[natemcmaster]

I don't think you should prioritize script-parsability over human readability. Script-parsability is good, but the info will typically be used by humans trying to figure out what's install. Scripting support is better solved by producing a truly machine-readable format. Other tools such docker and vswhere.exe support a --format flag. This makes parsing much safer and easier to do.

dotnet --info --format json
dotnet --info --format text

Example: try this:

PS> (& 'C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe' -prerelease -format json | ConvertFrom-Json).installationPath

[steveharter]

This issue is associated with a similar issue in dotnet/cli

So let's keep this issue for just the information the host gathers:

Microsoft .NET Core Shared Framework Host
...
The following .NET Core SDKs are installed:
...
The following .NET Core runtimes are installed:
...
To install additional .NET Core runtimes or SDKs:
...

[steveharter]

I don't think you should prioritize script-parsability over human readability

If we have a better format for --info I'm open for that. Then let's see if --list-runtimes and --list-sdks should be changed.

As far as parsing --list-runtimes and --list-sdks that was hypothetical although there will probably be some tool somewhere that will do that. If those end up being commonly parsed, then yes a --format approach like you suggested would be great for both parsing and a having a long-lived stable output.

Also assuming we are adding --list-runtimes and --list-sdks information to --info in theory we could remove --list-runtimes and --list-sdks (they were added in 2.1).

[steveharter]

@KathleenDollard

I'm still confused by the SDK and base path.

Base Path is just the SDK installed location. I suppose it's called "Base" because there are also other locations like the NuGetFallbackFolder used by the SDK.

[KathleenDollard]

Sorry Steve, I wind up putting this only in the other repo. I agree with the data, I'm struggling with the headings:

$ dotnet --info
SDK: dotnet version, reflecting any global.json:
  SDK Version:  2.1.300-preview1-002525
  SDK Build:    e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d

Runtime environment:
  OS Name:      Mac OS X
  OS Version:   10.12
  OS Platform:  Darwin
  RID:          osx.10.12-x64
  Base Path:    /usr/local/share/dotnet/sdk/2.0.0/

dotnet host (useful for support):
  Version  : 2.1.0-preview2-26129-0
  Build    : 5c7b2d33e76ee8052a6941a090fcd21252ce2ea8

.NET Core SDKs installed:
  2.0.0 [/usr/local/share/dotnet/sdk]
  2.0.3 [/usr/local/share/dotnet/sdk]
  2.1.3 [/usr/local/share/dotnet/sdk]
  2.1.300-preview1-002525 [/usr/local/share/dotnet/sdk]


.NET Core runtimes installed:
  Microsoft.AspNetCore.All 1.0.1 [C:\Program Files\dotnet\shared]
  Microsoft.NETCore.App 2.0.4 [C:\Program Files\dotnet\shared]
  Microsoft.NETCore.App 2.0.5 [C:\Program Files\dotnet\shared]
  Microsoft.NETCore.App 2.1.0 [C:\Program Files\dotnet\shared]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

Is adding JSON format realistic in your timeframe? I know that some folks like XML better, but is there a compelling reason for both (or for XML over JSON) @natemcmaster

[natemcmaster]

There may be an implementation reason to choose JSON - the dotnet host already has the "casablanca" JSON library baked in.

I have a slight preference for JSON. My primary use case for this would be in bash and powershell scripts.
Bash: there isn't a good XML parsing tool that we can install in our build scripts(AFAIK), but there's a really great one for json: jq.
PowerShell: offers both XML and JSON parsing in-box.

[steveharter]

JSON by default would be less readable. If we want to add a an option like dotnet --info --format json that is doable.

[KathleenDollard]

Completely agree default has to be human friendly.

We need to do the same thing host and CLI. @livarcocc for CLI

[KathleenDollard]

Is everyone good with the long ugly build number instead of the hash?

[natemcmaster]

Is everyone good with the long ugly build number instead of the hash?

Sorry, not sure I understand the context. Can you elaborate?

[KathleenDollard]

If you type dotnet --info today, you get

Commit SHA-1 hash:  0ca4e2c47b

for the SDK and

  Build    : 5c7b2d33e76ee8052a6941a090fcd21252ce2ea8

for the host.

I would like to be consistent and just randomly chose the second style. Is that good with folks?

[KathleenDollard]

$ dotnet --info
.NET Core SDK (reflecting any global.json):
  Version:    2.1.300-preview1-002525
  Commit:    98b69f28d

Runtime environment:
  OS Name:      Mac OS X
  OS Version:   10.12
  OS Platform:  Darwin
  RID:                osx.10.12-x64
  Base Path:    /usr/local/share/dotnet/sdk/2.0.0/

Host (useful for support):
  Version  : 2.1.0-preview2-26129-0
  Commit : 252ce2ea8

.NET Core SDKs installed:
  2.0.0 [/usr/local/share/dotnet/sdk]
  2.0.3 [/usr/local/share/dotnet/sdk]
  2.1.3 [/usr/local/share/dotnet/sdk]
  2.1.300-preview1-002525 [/usr/local/share/dotnet/sdk]


.NET Core runtimes installed:
  Microsoft.AspNetCore.All 1.0.1 [C:\Program Files\dotnet\shared]
  Microsoft.NETCore.App 2.0.4 [C:\Program Files\dotnet\shared]
  Microsoft.NETCore.App 2.0.5 [C:\Program Files\dotnet\shared]
  Microsoft.NETCore.App 2.1.0 [C:\Program Files\dotnet\shared]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

If there are no SDKs installed:

.NET Core SDKs installed:
  No SDKs were found.

If there are no runtimes installed:

.NET Core runtimes installed:
  No runtimes were found.