Sdk: Versioning Clarity

[PRIMETSS]

Seeing lots of posts on forums about versioning

Is it possible to have a a bit more clarity on what tooling/sdk/framework etc is installed on a machine?
can --info clearly list the
version of tooling
version of SDK's installed
version of framework

etc

@karelz

[davidfowl]

version of tooling

What's tooling?

version of SDK's installed

All of the versions of the The .NET CLI itself?

version of framework

All versions of the shared framework installed?

[livarcocc]

Indeed, can you answer fowler's questions? What are you trying to achieve?

Even if we did that, we would only be able to get these versions for the things installed next to the CLI that you are using (first in your path).

Also, I am not too keen of walking directory structures to find these things up, specially related to the shared framework, as from my point of view that would be breaking encapsulation.

[omajid]

Seems related to https://github.com/dotnet/cli/issues/3773, which is also discussing the version confusion.

[PRIMETSS]

I guess I'm just showing how someone not using it daily, or not involved from the initial start of all this, can get a little confused. Maybe Im not alone there? I think the confusion started when the SDK previews started rolling out, and the naming convention was a bit confusing. That I believe has been cleared up going forward.

anyway, thank-you as you have helped! I've got it now, its clicked!
This is embarrassing to admit, but I will share it as I believe this might be the reason why people get confused, and its all to do with 'global.json'
I think the download pages for the SDK's (both main and daily builds) need to state clearly, that if you are installing multiple versions, you need to create a local global.json file in your apps directory to tell dotnet what version of the SDK to use. If you dont, you will type dotnet [enter] and see you have installed say version 2.0.0.-preview.... (which is the 'Shared Framework Host' dotnet.exe)
but when use --info or --version to find out what SDK is being used, you will get the latest 'official release' version, or thats my understanding (it jumps only to official releases)
Sounds silly and basic, but thats my thoughts as to why some people are getting confused, they are just not getting the info on they need to create global.json.

...(edit)
but then again listen to the dotnet standup last week and sounds like all this has changed/changing

Time in 10:16sec

[livarcocc]

Yes. We are considering changing that policy (about preferring a released version over a semantically higher version, albeit pre-release).

[karelz]

@livarcocc we need to clarify in the --version output that the version is NOT Runtime/Framework being targeted. CLI is basically like VS - entirely independent on targeted Runtime/Framework, but the version are similar enough that it is confusing. We owe it to the customers to clarify.

If SDK / Runtime is not clear, or depends on project settings (most likely), let's point users to where to find that version. For example:

• CLI tools: v1.2.3.4
• SDK: See your.csproj, property CoreSDK (note: I am making it up as I have no idea what SDK is - I guess set of reference assemblies?)
• Runtime: Run command XYZ to list all installed SharedFrameworks, or look at your.csproj if you deploy local non-SharedFramework.

Given that even our top MVPs can't exaplain it to others (https://github.com/dotnet/cli/issues/3773#issuecomment-274088538) and that people on our own teams don't understand the stuff (count me in), I think we should provide some clarifications.
I'll be very happy to help shape the information to avoid confusion.

BTW: For me it feels like a dupe of dotnet/sdk#6569 and I would consider it ship-stopper for next CLI release.

cc @blackdwarf @kendrahavens

[am11]

After installing VS2017 on my box (and not removing VS2015 yet), I have dotnet v1.0.0 in PATH.
In CMD, I get:

C:\> dotnet --version
1.0.0

C:\> dotnet --info
.NET Command Line Tools (1.0.0)

Product Information:
 Version:            1.0.0
 Commit SHA-1 hash:  e53429feb4

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\1.0.0

If I check --version and --info in the directory of {global/project}.json based project (where SDK version is set to 1.0.0-preview2-003121), then it shows:

C:\> cd projects\ProjectJson-Based

C:\projects\ProjectJson-Based> dotnet --version
1.0.0-preview2-003121
:: ^at least this shouldn't be different

C:\projects\ProjectJson-Based> dotnet --info
.NET Command Line Tools (1.0.0-preview2-003121)

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

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

:: lets go one level up and check the version
C:\projects\ProjectJson-Based> cd ..

C:\projects> dotnet --version
1.0.0

:: and hence confusion++

So if the current directory has global.json or a project that depends on version X of SDK, dotnet --version && dotnet --info will show different output based on SDK vX. This is very strange and unusual.

[davidfowl]

So if the current directory has global.json or a project that depends on version X of SDK, dotnet --version && dotnet --info will show different output based on SDK vX. This is very strange and unusual.

You can't get away from that. The SDK versions are side by side and you can change global.json to pick a specific version for a solution. In this specific case it's required to function since later dotnet SDK versions don't support project.json.

What version would you rather see there? 1.0.0? We need a command that shows runtimes separately from the SDK version but the SDK still has its own version.

[am11]

We need a command that shows runtimes separately from the SDK version

Can the dotnet --version be changed to display the current version of host (aka muxer), v1.0.0 in case of aforementioned example? As dotnet --info is already showing the correct version of SDK that the project at CWD is using.

[davidfowl]

Can the dotnet --version be changed to display the current version of host (aka muxer), v1.0.0 in case of aforementioned example? As dotnet --info is already showing the correct version of SDK that the project at CWD is using.

Do you think the muxer version is relevant? If so why?

[am11]

In my understanding, the idea is that a host is capable of handling all SDKs (and SharedFx?) that predate it (the host/muxer) in release lifecycle. For example, in Kudu (Azure WebApps) environment, we have a latest dotnet.exe in PATH, that is capable of handing solutions depending on varied SDKs that are installed.

Do you think the muxer version is relevant?

That is a matter of answering the question:

What version of dotnet (as in dotnet-cli) are you running? (analogous to "what version of git you are using")

as:

v1.0.0 ; which implies "it can handle all SDKs/SharedFx versions that are available on the system. For more information on SDK version for a specific project, cd into your project dir and run dotnet --info"

rather than:

It depends on the version of SDK your project is relying on. dotnet.exe version is irrelevant.

[davidfowl]

In my understanding, the idea is that a host is capable of handling all SDKs (and SharedFx?) that predate it (the host/muxer) in release lifecycle. For example, in Kudu (Azure WebApps) environment, we have a latest dotnet.exe in PATH, that is capable of handing solutions depending on varied SDKs that are installed.

Not necessarily true. Everything is side by side, the shared framework and the SDK.

We can show the muxer information in --version and more detailed information in --info but that solves nothing IMO and is pretty artificial.

[PRIMETSS]

heh on a light note:-

Maybe just rename 'dotnet.exe' to 'thethingthatmakesstuffhappen.exe' and --version --info just says 'dont worry about it!'

[davidfowl]

yes versioning is hard, who knew?

[omajid]

Can the dotnet --version be changed to display the current version of host (aka muxer), v1.0.0 in case of aforementioned example?

Running dotnet/dotnet.exe by itself does exactly that, afaict. At least, it prints a version that is not the sharedframework version and not the sdk version

[am11]

@omajid, but I have found different results: https://github.com/dotnet/cli/issues/6015#issuecomment-287598121

[livarcocc]

We cannot change --version. The intention of that command is to allow for build scripts to inquire the CLI version and to not have to parse anything. It returns one string back and it is the SDK version.

Also, I agree with @davidfowl. Display the version of the muxer gives you nothing. The relevant information is the SDK (which contains your tools) and the runtime.

There is a discussion going on about this here: https://github.com/dotnet/cli/issues/3773. Let's continue it there. Closing this one.