Sdk: .NET Core Installer vs .NET Core Cli Installers is confusing

Created on 25 Mar 2016  路  14Comments  路  Source: dotnet/sdk

I installed .NET Core Installer and wanted to confirm that I have the latest version and got:

PS C:\WINDOWS\system32> dotnet --version
Could not resolve SDK directory from [C:\Program Files\dotnet]

I did see that --help options in the new thing were limited but was not aware that I need a different installer to do my dev work. This is quite confusing since the tutorials say you should do dotnet build, dotnet run etc. but if you install just the Core Installer nothing of this works. The message and --help is very unhelpful either.

Most helpful comment

Yes, @anurse explained it too me. But users don't have @anurse or you around - the message should make it possible to figure it out on my own. At the moment is is not helpful.

All 14 comments

@moozzyk The Core Installer is intended to place the shared framework and host only on your machine.

In this way it can be used for running apps, but not building them.

The .NET Core Cli Installer is what you are looking for

Yes, @anurse explained it too me. But users don't have @anurse or you around - the message should make it possible to figure it out on my own. At the moment is is not helpful.

Totally agree! any suggestions there?

cc @blackdwarf

the .net core one should be called something like .net core runtime.

I prefer "Runtime" and "SDK" as distinctions. Also, the muxer should be capable of responding to --version at some point before RTM :)

:+1: about .NET Core Runtime

And maybe .NET Core CLI can be just .NET CLI, because it can build all targets, not only .NET Core.
It's already a good name, short

image

I prefer "Runtime" and "SDK" as distinctions. Also, the muxer should be capable of responding to --version at some point before RTM :)

:+1: for .NET Core Runtime and .NET Core SDK installers.

@richlander @blackdwarf regarding branding.

@schellap regarding --version in the muxer

OK, thought about this a little. Here is the suggestion from me:

  • .NET Core Runtime

    • Shared runtime + host

  • .NET Core Software Development Kit (SDK)

    • .NET Core Runtime vx.0.0.y

    • .NET Core Tools va.0.0.b

    • In the future:

    • Docs

    • Samples

Thoughts? I'm still thinking we should just leave the CLI to be called CLI. There are many examples of this. But I've put "tools" here since it is slightly less confusing in the .NET Universe (where CLI == else).

/cc @piotrpMSFT @richlander @Petermarcu @anurse @brthor

I think Tools is confusing because we have a separate concept of cli tools in the project.json.

It's not too bad, but every time we talk about tools we'll need to point out which tools we're talking about.

You could call it .NET Core Command Line Interface (CLI) similar to the SDK. I agree that Tools is more confusing even though there are different CLI meanings.

@brthor @akoeplinger good, I actually would like to leave it as CLI. :) Grew on me, we are all using it, the people outside are using it and there is a lot of precedent in other products.

There is a PR where you can share your opinions: dotnet/cli#2147

Actually, this is solved now I believe, since we have a different branding in place. :) Will close, please reopen if the issue still persists.

Was this page helpful?
0 / 5 - 0 ratings