Sdk: 1.0 CLI versioning is confusing

Created on 16 Feb 2017 · 7Comments · Source: dotnet/sdk

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.

Source

davkean

👍8

Most helpful comment

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.

davkean on 16 Feb 2017

👍2

All 7 comments

cc @leecow @blackdwarf since we were talking about this earlier this week.

livarcocc on 16 Feb 2017

that's new, versioning name and branding was never an issue with cli or .net core before...

enricosada on 16 Feb 2017

Definitely confusing and as @livarcocc notes, we're talking about how to make it better. To make matters a little more confusing, the install dialog has become even less accurate now that both 1.0.x and 1.1.x Share Frameworks are included.

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

leecow on 16 Feb 2017

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.

davkean on 16 Feb 2017

👍2

No argument from me.

leecow on 16 Feb 2017

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.