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.

[blackdwarf]

@factormystic what is required for the powershell package/chocolatey options? I admit not knowing what is required to make that work.

@guardrex as @shahid-pk said, living on the bleeding edge does require some effort. :) You can also take a look at the install.ps1 script in this repo to see if it can help you with this predicament.

[guardrex]

@shahid-pk @blackdwarf ... no, no ... if I gotta do what I gotta do ... i'm all good. I have one dotnet cli app in production now ... three days and no probs with that app, and I'm just anxious to get everything moved (and to Nano, too) asap. You know how it is. I'm just asking the ?: Is there a better way to keep dotnet cli tools updated than this medieval torture that I'm enduring today.

[andyleejordan]

@guardrex Switch to Linux where we've had package managers for ages, the torture will stop!

[blackdwarf]

@andschwa do you also give out cookies? :)

All jokes aside, since we had this discussion, I would close down this issue if you all agree. Of course, would love to hear from @factormystic about what it takes to create a Chocolatey package...

[andyleejordan]

@blackdwarf One free fortune cookie with every new terminal session 🍪

[blackdwarf]

@andschwa ROFL. :)

[TanukiSharp]

A tool like nvm would be great.
And thus allowing dotnet to support side-by-side installs would also be great.

In production one often want to freeze a version of the runtime, no matter it is buggy or what, until the application can be tested with another version, and then switched.

dnvm is trying to do the same job, which is a good news, however I still do not understand why this seems to be strongly tied to ASP.NET...

[blackdwarf]

Well, we've decided that we will not use this, so closing.