What should dotnet --version display?

[neman]

Steps to reproduce

I installed .NET Core SDK for Windows.
When I type dotnetin pwsh it showed

Microsoft .NET Core Shared Framework Host

Version : 1.0.1
Build : cee57bf6c981237d80aa1631cfe83cb9ba329f12
Usage: dotnet [common-options] [[options] path-to-application]

Common Options:
--help Display .NET Core Shared Framework Host help.
--version Display .NET Core Shared Framework Host version.

...

When I type `dotnet --version it shows

1.0.0-preview2-003121

Expected behavior

I don't know what is expected behaviour.

Actual behavior

I have 2 different versions showing.
One is 1.0.1 and the other one is 1.0.0-preview2-003121

Is this a bug? Microsoft .NET Core Shared Framework Host show different versions or first version is .NET Core version so the problem is only within label name?

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-preview2-003121)

Product Information:
Version: 1.0.0-preview2-003121
Commit SHA-1 hash: 1e9d529

Runtime Environment:
OS Name: Windows
OS Version: 10.0.10240
OS Platform: Windows
RID: win10-x64

[dasMulli]

1. It is by design.. there are multiple components to the cli: muxer, shared host, shared framework, SDK.
2. I do think the wording cold be better as the dotnet --help command will call out to the SDK but the help text is "Display .NET Core Shared Framework Host help". If you don't have an SDK installed, you will get the same info for no arguments, --help, and --version.

[vcsjones]

There have been a number of issues filed, confusion on Slack channels, and on twitter about the meaning of dotnet --version.

Proposal: dotnet --version should print all relevant information. Something like this:

CLI Tooling: 1.0.0-preview4-004130
Microsoft .NET Core Shared Framework Host: 1.1.0
MSBuild: 15.1.0.0

The only reason I could think of as why this would be a bad idea is if the output of --version was meant to be parsable / consumable by other tools.

[omajid]

@vcsjones Agreed. The only suggestion I have for your proposal is that the most important version number should be displayed first. I think most users will care about the .NET Core version first and foremost, so, ideally, that should come first.

[am11]

+1 for @vcsjones's proposal with an addition of NuGet version. :)

meant to be parsable / consumable by other

Agree, parsers will need to split by linefeed then by colon to get proper key value pairs, but if the --version output format and order is frozen once and for all (future tools listed at the bottom), that would be A-okay IMO.

[vcsjones]

Agree, parsers will need to split by linefeed then by colon to get proper key value pairs, but if the --version output format and order is frozen once and for all (future tools listed at the bottom), that would be A-okay IMO.

My concern is if there is a tool already that reads the entire string, like Visual Studio RC, to figure out the version of the SDK installed. That would mean changing this would break VS, which is probably a no-go.

If there is no tooling that already depends on this behavior, then line feeds are an option. Alternatively, --version could take an argument to return a specific thing, like --version sdk or --version msbuild, etc and it would instead literally print that version number like it is today.

[blackdwarf]

I would disagree with changing the --version for this. It was introduced precisely because it gives back only the CLI version; this is how most of the other CLI toolkits out there that have two different ways to report versions work. Changing this would break people.

We do have the --info and we are exploring how to make that better. This suggestion is good and could go into --info along other information that is relevant (for instance, the host information).

@omajid users can potentially have multiple .NET Core shared runtimes installed on a single machine, so which one would be the one to bubble up? For example, I currently have 1.0.0, 1.0.1 and 1.1.0 on my machine. I believe that we should do something else to allow listing of installed runtimes.

[vcsjones]

this is how most of the other CLI toolkits out there that have two different ways to report versions work.

Not to disagree with you, but really to answer my own curiosity, can you give an example?

We do have the --info and we are exploring how to make that better

That's great. I would also consider improving what is displayed when dotnet is run with no arguments at all. Most things that I use use that for the REPL, but I don't think that's coming down the pipe any time soon.

Here's a dump of all of my silly thoughts.

1. --info should include the runtime version. Please, somehow, think of something better to call it than "Microsoft .NET Core Shared Framework Host".
2. Please add --info into "Common Options" when dotnet is run with no arguments. I realize it's there under --help already, but I feel this is going to be a common question.
3. It's weird that dotnet --version, dotnet --info are affected by the global.json's "sdk". Ideally --info would show all your SDKs installed, somehow. Even if I had preview4 installed, but run dotnet --info in a directory which has a global.json SDK for preview2, it returns the preview2 version. This is technically right behavior, but it still doesn't seem quite right. I'm not aware of any other platforms like dotnet that do muxing like this, so I can't think of a better way to do it.

[omajid]

@omajid users can potentially have multiple .NET Core shared runtimes installed on a single machine, so which one would be the one to bubble up?

@blackdwarf If there's multiple possible versions and any of them will work, maybe list them all?

[dasMulli]

The wording is quite inconsistent at the moment.
dotnet tells me:

...
Microsoft .NET Core Shared Framework Host

  Version  : 1.1.0
...
Common Options:
  --help                           Display .NET Core Shared Framework Host help.
  --version                        Display .NET Core Shared Framework Host version.

So. i just saw "Shared Framework Host version 1.1.0" and "--version shows the shared framework host version".
But dotnet --version really tells me the CLI version (1.0.0-preview4-004079).

[dasMulli]

Also there is --version and --fx-version which look similar, but one is actually a verb ("show version"), the other one is an option. This could be made more distinct (--use-fx-version 1.0.3 for example. with --fx-version still being supported for compatibility).

[blackdwarf]

@vcsjones hm, I was sure I saw this behavior in node that it has two distinct outputs. Just tried it and it seems my memory is not what it was, since it has just one. To be fair though, both node and python display just their version on --version. To your other very good points, here is a summary reply (hope that works):

That's great. I would also consider improving what is displayed when dotnet is run with no arguments at all.

Yes, we are working on fixing this as it is super confusing to have 3 distinct versions (host, tooling and fx) to have to contend with, 2 out of which have

--info should include the runtime version. Please, somehow, think of something better to call it than "Microsoft .NET Core Shared Framework Host".

The host and the runtime are distinct components. 🙂 The runtime version is not displayed anywhere, which is what @omajid is asking for (see response below on that)

It's weird that dotnet --version, dotnet --info are affected by the global.json's "sdk". Ideally --info would show all your SDKs installed, somehow. Even if I had preview4 installed, but run dotnet --info in a directory which has a global.json SDK for preview2, it returns the preview2 version. This is technically right behavior, but it still doesn't seem quite right. I'm not aware of any other platforms like dotnet that do muxing like this, so I can't think of a better way to do it.

I think we should leave it like this because that is the fastest way to check on what version you are and as you quite nicely said, it is technically correct behavior. We could see if a feature can be made at some point in the future that would list out the SDKs installed, but I'm not too sure if this is the way forward. Need to think on this.

@omajid

@blackdwarf If there's multiple possible versions and any of them will work, maybe list them all?

I'm in favor of having this capability in the CLI, just not as part of the --info or --version. I was thinking of adding at some point a --runtimes switch, for example, that would list out all of the runtimes that are near your host. I guess I'm following the underlying need here which is to have an easy gesture to list out the runtimes that you have installed on the system, correct?

[omajid]

@blackdwarf My primary concern is that I get the following question when I point someone to .NET Core 1.1: "Why is the version 1.0.0-preview2-1? Did I install it incorrectly?" (see also https://github.com/dotnet/cli/issues/4864). This happened with multiple people, some of them who are generally much more knowledgeable than me when it comes to .NET. It seems to me that it's not obvious to many people that host, runtime (and cli?) are separate things. As far as I can tell, they ask for the version of .NET Core 1.1 and are confused when it doesn't say "1.1". Not many go as far as dotnet --info (this isn't as standard/obvious a flag as --version).

A --runtimes flag is nice to have, but I am not sure if it will help address the questions I have seen.

If a comparison to other languages/tools helps:

$ python --version
Python 2.7.12
$ python3 --version
Python 3.5.2
$ java --version 
openjdk version "1.8.0_111"
OpenJDK Runtime Environment (build 1.8.0_111-b16)
OpenJDK 64-Bit Server VM (build 25.111-b16, mixed mode)
$ gcc --version -Q
gcc (GCC) 6.2.1 20160916 (Red Hat 6.2.1-2)
Copyright (C) 2016 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.
$ lua -v
Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio

Most other languages/projects seem to show the language's (or the runtime's) main version with the --version flag. None of the languages I tested print out the version of the driver ("cli") program. Given the existing set of tools out there, it seems very confusing to users if the dotnet cli program prints a version unrelated to the version of the rest of .NET Core.

[vcsjones]

they ask for the version of .NET Core 1.1 and are confused when it doesn't say "1.1".

Yes. That's more or less the issue. The issue is too many version numbers and discoverability.

That's why I was advocating for a single option, like --info, that dumps everything. The Muxer, Runtime, MSBuild, CSC, etc.

The question boils down to what is "the" version of .NET you have installed. The latest runtime? The current version of the tooling? It's marketed as the version of the runtime, more or less. Whatever "1.1" is, it's surprisingly hard to find it in the output of the .NET CLI.