dotnet update

[blackdwarf]

We need to discuss whether having a command to update the CLI tooling to the latest stable/unstable version is useful.

Relies on information from #4582 somewhat.

[blackdwarf]

/cc @richlander @gkhanna79 @piotrpMSFT

[andyleejordan]

Since dotnet already deploys distribution packages, as a user, personally, I prefer to update via the package manager, and would find it confusing to override the program installed from a package with a self-update command.

[ctolkien]

👍
Would like to see this.

[guardrex]

... agreed ... please ... 👍 for dotnet update-self

[davidfowl]

We can't have install mean nuget and update mean updating the CLI. Also, you shouldn;t be installing via a package manager and updating via the CLI. That's pretty weird.

[guardrex]

??? update != update-self

"deploys distribution packages" and "package manager" ... I'll read about tomorrow. My current process of updating via MSI is a pain, so I need to move to a better process with daily dotnet tooling upgrades.

[guardrex]

@davidfowl By "package manager," do you mean VS package manager? If so, I'm using VS Code right now. I'm installing dotnet with the MSI; therefore, I'm confused by wanting to have dotnet update-self as "weird." How is it wrong/bad to want this functionality?

[davidfowl]

By "package manager," do you mean VS package manager?

No, MSI on windows, apt-get on debian and pkg on OSX. If you use those installers to get the first dotnet and you update dotnet via the built in "self update", only bad things can happen.

[guardrex]

I see. So my process is ok ... just tedious, i.e., downloading and installing MSI's as they become available. It will be nice when the dotnet cli page shows the version, if that's where https://github.com/dotnet/cli/issues/1000 is headed.

[factormystic]

👎 on the OP's request, this should be handled not by the tool itself, but by whatever mechanism is responsible for delivering the tool. And I hope that will eventually mean powershell package management on Windows. I agree with @guardrex that manually visiting some web site and downloading some msi and double clicking it is a super lame acquisition story, especially in 2016, especially compared to other OS's.

[shahid-pk]

👎 cli tool should not do a package manager or installers job. Some tools like PHP's composer do that but we should not be following bad precedence.

[blackdwarf]

I don't see us doing this, really. One of the main principles of this toolset is that we want to rely on each OS' native install story, as it is baked pretty well and as all of the users of a given OS are familiar with it (for better or for worse). @davidfowl said it right, if we go down this route, we may end up in all kinds of weird situations that would be all-around badness.

PowerShell package management is definitely an option, there is an issue that mentions that on here, I believe it is dotnet/cli#1064.

If you want to decrease the problem of installing the MSI, you can always use the zips and some scripting to automate the local install by essentially overwriting the tools in a well-known location that you have env variables pointed to.

[guardrex]

@blackdwarf Can you admit that looking at a webpage ... comparing the version to what you have installed (if you can remember) ... downloading manually (with some command or clicking on something) ... and running the installer (from wherever the hell the installer ends up) ... can you see the iNsaNitY of all of this when you have almost daily builds of the tools and your trying to use VS Code because the VS experience is .. well ... about like going to the dentist? See what I mean? This is a waste of my time.

[shahid-pk]

@guardrex completely not in favor of starting a flame war or debate over this but just adding my opinion.
I think nightly-builds are generally installed by very few and those few already know the pains of using a beta or alpha software so daily installers should be a none issue to them. they can automate that using a script 😄
Normal users or majority of the users will just pick a stable installation and use if for months or years until the next stable release of the tool and it is true for those too who will use it at work.