Sdk: Getting started with latest dotnet core using command line not clear

[jpierson]

Steps to reproduce

1. Go to any intuitive landing page for dotnet core (ex. github.com/dotnet/cli, dot.net)
2. Following available documentation for command line use on Windows
3. Attempt to use dotnet cli (ex. dotnet --help)

Expected behavior

A command line centric setp of steps to install all necessary prerequisites and installation files (ex. chocolatey...) for the latest stable release of the dotnet cli and a working cli with the correct version reported after install. Ultimately I would like to or expect to be able to update both the cli tools and the .NET Core versions independently from eachother both from the command line. In this case I'm trying to get onto the newer .csproj based support so that I can begin writing .NET core projects that one have to be migrated from project.json.

Actual behavior

A mixed command line, Visual Studio, and manual non command line centric installation steps followed by what seems to be non-current version of .NET CLI tools or .NET Core being used in the environment.

From dot.net

The latest LTS SDK is reported to be .NET Core 1.0.3 SDK but the link downloadds a file called dotnet-dev-win-x64.1.0.0-preview2-003156.exe. The installer says it's installing .NET 1.0.3 but SDK 1.0.0 Preview 2.

The most Current SDK is reported to be .NET Core 1.1 SDK but the link downloads a file called dotnet-dev-win-x64.1.0.0-preview2-1-003177.exe. The installer mentions that is installing Core 1.1.0 but SDK 1.0.0 Preview 2.1.

From GitHub Readme.md on the default branch rel\1.0.0

The latest version is reported to be Preview 4 with no significant mention of the major.minor version number. A link in this section leads to a set of downloads which for Windows downloads and installer file named dotnet-dev-win-x64.1.0.0-preview4-004233.exe. The installer says it is installing .NET Core 1.0.1 and SDK Preview 4. Again no mention of the SDK major or minor version and unintuitively it seems that we are back on .NET Core 1.0.1 instead of moving forward with .NET Core 1.1.0 as would be expected from prior SDK Preview 2.1.

Later in the Installers and Binaries section it points to what appears to be a latest development build which downloads a file called dotnet-dev-win-x64.latest.exe. Installer still shows that is installing .NET Core 1.0.1 and SDK Preview 5.

From .NET Core installation guide for VS 2015 users.

The guide suggests downloading ".NET Core 1.0.1 tools Preview 2" which links to a file called DotNetCore.1.0.1-VS2015Tools.Preview2.0.3.exe. The installer says it will install .NET Core 1.0.1 and VS 2015 Tooling Preview 2. Is "Tooling" supposed to be the same as SDK Preview 2?

From the .NET Core installation guide for Command line / other

The guide suggests downloading ".NET Core 1.1 SDK" and links to the same file as the "Current" release noted above dotnet-dev-win-x64.1.0.0-preview2-1-003177.exe.

Environment data

dotnet --info output after installing DotNetCore.1.0.1-VS2015Tools.Preview2.0.3.exe, dotnet-dev-win-x64.1.0.0-preview2-1-003177.exe, and dotnet-dev-win-x64.1.0.0-preview4-004233.exe:

.NET Command Line Tools (1.0.0-preview3-004056)

Product Information:
 Version:            1.0.0-preview3-004056
 Commit SHA-1 hash:  ccc4968bc3

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

Possibly related:

• https://github.com/dotnet/cli/issues/5009
• https://github.com/dotnet/cli/issues/5046
• https://github.com/dotnet/cli/issues/1693

[jpierson]

Running dotnet new does seem to produce a .csproj based project for me which I didn't expect based on the version number reported by both the dotnet --info or the dotnet --version commands as noted above. So from what I can tell it appears that the installers did their job. I would still have a more consistent way to accomplish the "SDK" installation from the command line in Windows and in perhaps a way that gives more clarity that the latest version is in fact installed and in use. I'm thinking along the lines of dnvm, or nvm. Perhaps this is under development but I just haven't found the specific place where it is being tracked.

_Side Note_: It appears that dotnet new produced a project with a default taget of netcoreapp1.0 and references to packages Microsoft.NET.Sdk and Microsoft.NETCore.App which are not intuitive to me from a historical .NET Framework perspective. Running dotnet run doesn't seem to work on this project either as it seems OutputType is not "runnable". I suppose that's where I'll be digging into next as a simple google search hasn't turned anything up yet but I would double that there is anything more than a slim chance that these particular problems are directly related to the issues I had installing the SDK as described above.

[livarcocc]

@blackdwarf

[dmumladze]

@jpierson could you please list C:\Program Files\dotnet\sdk content from your machine and attach project.json from relevant project? I'm on the path of solving very similar issue...

[jpierson]

@dmumladze, here is what is under C:\Program Files\dotnet\sdk on my machine. As for a project.json file there is none that is relevant since I was only attempting to get the current tooling set up first and did find that running dotnet new did in fact produce a .csproj file as I wanted but presumably it was the preview3 tooling that is reported on my machine that is likely responsible for this.

    Directory: C:\Program Files\dotnet\sdk


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----       12/26/2016   9:01 PM                1.0.0-preview2-003131
d-----       12/26/2016   9:12 PM                1.0.0-preview2-1-003177
da----       12/26/2016  10:35 PM                1.0.0-preview4-004233

[blackdwarf]

@jpierson there are a couple of things you highlighted that we are aware of as the problems. Before I dig into that, lets get the simple thing out of the way. https://github.com/dotnet/cli/tree/rel/1.0.0/scripts/obtain contains two installation scripts, dotnet-install.sh and dotnet-install.ps1 for UNIX and Windows respectively. These scripts will allow you to install the SDK and the runtime from the command line.

I will list out my understanding of the issues you raised as well as the status of each, so please do ask/correct if I got something wrong or you need more info:

1. The installer filename versions are confusing - this is true, and there is a plan to fix this in the future. The current state is also exacerbated with the fact that the tools are in Preview and that we have 2 project systems in existence. It will start becoming better when the tools hit 1.0.0 and we move to just one project system (csproj).
2. The SDK versions don't have good minor versions - similar to the above, an artefact of the current state of tools where they are in Preview.
3. Preview 5 on the README in GitHub - this is actually easy, the rel/1.0.0 is the latest. We have separate branches and publish separate installers for other versions, while the rel/1.0.0 points to the latest and greatest both in features as well as the version.
4. I need a way to install runtime and SDK separately - you actually have this today. You can go to https://www.microsoft.com/net/download/core#/runtime and download installers/binaries just for the runtime.

I'm slightly weirded out by the fact that you managed to get a preview 3 of the CLI on the path even though in the screenshots in the issue you never seem to install Preview 3 bits. Did you, by any chance, install VS2017 at some point?

[jpierson]

@blackdwarf, Thanks for your detailed response.

As far as the Preview 3 bits go, I could be wrong but I believe I installed this through VS 2015 as an extension update or by installing the SDK manually at some point earlier in the _Connect_ timeframe. My point of confusion was and still is why installing what seems to be newer versions of the SDK doesn't change the reported tools version when running dotnet --info. I'm assuming that when running other dotnet commands that I'm getting Preview 3 behavior as well but I don't know of a clear way to determine this.

On another note I found an article about migrating from dnx which I think gives a clue about my issue.

The CLI tools come packaged in two main ways, as was explained in the overview document:

1. Native installers for a given platform
2. Install script for other situations (like CI servers)

Given this, the DNVM install features are not needed. But what about the runtime selection features?

You reference a runtime in your project.json by adding a package of a certain version to your dependencies. With this change, your application will be able to use the new runtime bits. Getting these bits to your machine is the same as with the CLI: you install the runtime via one of the native installers it supports or via its install script.

It seems that unlike the original _dnx_ _dnvm_ experience that the new tooling is moving towards the manual desktop installers and what seems like away from the command line centric approach made popular with environments such as ruby, node/npm/nvm, rust/cargo. My understanding may have been incorrect but I got the feeling that installing runtimes with the original dnx tooling was a lightweight concept that may even be isolated to a given user or path whereas with the .msi installer I get the felling like I'm installing a large framework system wide. Maybe this is just perception but at least from this article it sounds like the difference may be intentional. The original documentation and articles on dnx seemed to keep everything in the command line starting from installation and including installing updates and I want to understand whether the intention is reintroduce this approach once the tooling is further refined or if it is a preference to avoid command line approach. I'm remaining optimistic that things have been pulled back and re-prioritized for VS developers and then proper emphasis will be given to match or exceed the experience of other command line centric development environments in the near future.

[blackdwarf]

@jpierson sorry for the late reply. :(

VS2015 should not be bringing in Preview 3 bits as VS2015 is still project.json-based tooling. Now, when you say that running dotnet --info gives you older versions than what you installed, can you check if you have a global.json in your solution with a specified sdk version? This could actually impact that. Another thing could be the order of the directories in your PATH.

For the other aspect, we have scripts that can help you install into whatever location is needed. They can be found in the scripts/obtain directory in this (CLI) repo. But yes, this was a move to decouple the tooling from the runtime since DNX was, to a point, both things combined into one package.

We are looking into different modalities for acquisition and how to make that experience even more streamlined. Stay tuned! 😃

[jpierson]

@blackdwarf As for global.json I was running this command sans any project/solution (ex. C:\). I double checked that there was no global.json file in the root of where I'm running the command and still the same result.

We are looking into different modalities for acquisition and how to make that experience even more streamlined. Stay tuned! 😃

Awesome! I'm excited to hear about it. I would love to be able to download a new project from GitHub for example and have some base level of the .NET Core tooling download the necessary runtime/dependency pacakges needed to build, run, and package that project all without having to manually download additional _.msi_ files.

[sophistyx]

Why is this so confusing? Seriously. It's a total joke. How long has this been in development and yet you can't get the basic versioning, tooling and even a standard project system in place? Is it any surprise people are moving to Node.js en-masse? I've been writing .NET Code since beta in 2001 so it gives me no pleasure saying this but it does give serious concern about your direction.

[jpierson]

Last night I went over to take a peek again at the state of the Rust Language ecosystem and found a great examples of what I'm after.

https://www.rustup.rs/

http://doc.crates.io/

I think things are close but unfortunately it feels like we have taken a few steps back with the tooling reset and there is not clear direction on intentions on getting back.

[livarcocc]

Closing older issues.