What should dotnet --version display?

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: 1e9d529bc5

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

[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.

[NickCraver]

FWIW, I just tried to explain this to someone…and I couldn’t. They could not understand how things relate and how to correlate their --version to the website. I agree this really needs to change. People don’t develop in the .NET tooling, the .NET runtime, and the .NET SDKs. This is a migration painpoint because users have gone from:

I’m on .NET 4.6.2

to

I’m on: CLI: ________ SDK: _________ Runtime: _________

Basically we’ve replaced the .NET ecosystem with a bunch of exposed bits the user usually shouldn’t be caring about. While this was fine during the transition for the power users involved here, it is definitely not okay going forward. The least we can do would be to simplify the gap and make it easy for the user to access all the bits they’re on when getting help. Imagine what a user has to do on a build server to figure this out today. It’s not intuitive, and is a large step backwards which will hurt migrations to .NET Core. I really wish this would be reconsidered for 1.0.0.