1.0 CLI versioning is confusing

1.0 CLI versioning is very confusing:

Installing the SDK shows me:

Running dotnet, shows me:

Microsoft .NET Core Shared Framework Host

  Version  : 1.1.0
  Build    : 928f77c4bc3f49d892459992fb6e1d5542cb5e86

[...]

Running dotnet --version, shows me:

D:\Mvc>dotnet --version
1.0.0-rc4-004828

I would expect some of these versions to have some relationship with each other. When someone asks, “what version of CLI are you running?” I don’t know what answer to give them.

[davkean]

I believe dotnet will return the Shared Framework version on which the CLI is running. dotnet --version returns the CLI version.

That to me is confusing. List them both.

[blackdwarf]

This is not quite true I believe. The dotnet on its own will return the host’s version. --version will return the CLI version. Now, --version was added precisely to return a single string which is the CLI version. Changing that now would mean breaking people who use it, for example, in their build scripts. Luckily, we have --info that can (and will in the future) contain more info about all of the moving pieces so users can reason about it.

Now, as for shared framework version, there were a lot of discussion on another issue on GH about what to show for the shared fx. Don’t forget, users can have multiples of these installed. So, we could return the one that the CLI runs on, which, in general, I don’t see how useful it is; it is an implementation detail, is it not? Nothing prevents the user from installing a completely different one and then getting the one that the CLI runs on would again become confusing.

A suggestion I had was to introduce dotnet list runtimes that would list out all of the versions that the host that is currently on the $PATH (the one that executes the command) has access to.