Sdk: dotnet tool install should return exit code 0 if tool is already installed

[natemcmaster]

I'm trying to write a script that will install global tools if necessary. I would like to just run "dotnet tool install", but this returns exit code 0 if the tool is already present, so I have to first execute dotnet tool list and grep the output.

Expected behavior

Calling dotnet tool install should no-op AND exit code 0 if the tool is already installed

Actual behavior

Running dotnet tool install twice fails scripts because the second time it runs it will exit code 0

PS> & dotnet tool install --tool-path "$(pwd)/.tools" sleet --version 2.3.25 --add-source https://api.nuget.org/v3/index.json
You can invoke the tool using the following command: sleet
Tool 'sleet' (version '2.3.25') was successfully installed.
PS> $lastexitcode
0
PS>  & dotnet tool install --tool-path "$(pwd)/.tools" sleet --version 2.3.25 --add-source https://api.nuget.org/v3/index.json
Tool 'sleet' is already installed.
PS>  $lastexitcode
1

The result of this is that I have write more complicate code like this:

if (& $dotnet tool list --tool-path "$PSScriptRoot/.tools" | Select-String "sleet") {
    Write-Host -f Yellow 'Skipping install of sleet. It''s already installed'
}
else {
    Invoke-Block { & $dotnet tool install --tool-path "$PSScriptRoot/.tools" sleet --version 2.3.25 --add-source https://api.nuget.org/v3/index.json }
}

Environment data

dotnet --info output:

.NET Core SDK (reflecting any global.json):
 Version:   2.1.300
 Commit:    adab45bf0c

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17134
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\dev\aspnet\Universe20\.dotnet\sdk\2.1.300\

Host (useful for support):
  Version: 2.1.0
  Commit:  caa7b7e2ba

.NET Core SDKs installed:
  2.1.300 [C:\dev\aspnet\Universe20\.dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.0 [C:\dev\aspnet\Universe20\.dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.0 [C:\dev\aspnet\Universe20\.dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.0 [C:\dev\aspnet\Universe20\.dotnet\shared\Microsoft.NETCore.App]

[wli3]

Another side of the coin will be "I don't know if it will trigger asset download if I run this command". I slightly prefer current approach. But note, both approach will cause another side unhappy.

[natemcmaster]

Another side of the coin will be "I don't know if it will trigger asset download if I run this command"

Can you explain more what you mean? I'm not sure I understand the concern. It seems clear to me that when calling "dotnet tool install" I may download some assets.

[wli3]

related issue https://github.com/dotnet/cli/issues/9064

If exists return 0 has extra magic. The installation is triggered or not depends on the existing disk state. The current approach i think is more strict which is better for script since it is less likely to swallow error in script.

Also, "dotnet tool install" is not idempotent at all. It will download a different version if there is new version in the feed. In this case, what "dotnet tool" install should do when this happens and what the user will expect? And the expectation will also be different for scripting and user typing. The current strict approach will move this question to the user which I think is better than mismatch expectation.

[natemcmaster]

This is overly strict and IMO a bad default. The error code currently issued (exit code 1) is the same error code issued for legitimate errors, so I can't just swallowed the error and move on.

You've brought up a good point though -- what to do about versions. IMO it would be good to look at what other tools do, e.g.

brew install
apt-get install
npm install

From my experience with these, running install (without a version) will return exit code 0 and will not attempt to upgrade if the tool is already installed. Running install with a version will attempt to run and upgrade (or downgrade) to bring the installed tool into alignment with the value of --version

cc @KathleenDollard @richlander

[tmds]

npm install returns 1 when it can't change to the specified version.
npm install returns 0 when the version is already installed.

npm install without a version specified will update to the latest version when the package is already installed.

This matches my expectations as a user.

[KathleenDollard]

Will and I talked about this.

We do not currently determine what the version of a tool is. Install fails if it is found, update uninstalls and reinstalls it regardless. And, we're concerned about users being able to differentiate between "we didn't do anything" and "we think you are in a broken state".

All of this relates to a decision we're working on regarding whether we use a manifest for repo tools (expected) and whether we retrofit that approach to global tool or have two different internal approaches. If we change global tools to maintain manifest, it will be easier for users to understand what they have requested, for us to understand the version that is present, etc.

So, this is on hold for a bit.

[ErikSchierboom]

npm install returns 1 when it can't change to the specified version.
npm install returns 0 when the version is already installed.

npm install without a version specified will update to the latest version when the package is already installed.

This matches my expectations as a user.

I agree!

[wli3]

Please continue comment this issues if you think https://github.com/dotnet/cli/pull/10205 cannot solve the problem of your scenario and I will reopen it

[cottsak]

It's so frustrating not to get the common convention of a 0 exit when the tool installs or is already present.

[KathleenDollard]

@cottsak Is there a reason using dotnet update instead of dotnet install is a bad choice when you want to either install or update depending on whether the tool is on the box?

[cottsak]

@KathleenDollard It's not a "bad" choice. But IMO, it's less than ideal. When scripting something it would be great to simply use dotnet install as an idempotent command meaning that it will implicitly "install" if not present, or return 0 if it's already installed. It just makes life easier, and seems to be an established convention.

[sandcastle]

I honestly think if a survey was run (focused on ux), it would clearly show that the current behaviour is not preferred. It's inconsistent with so many other experiences like the ones @natemcmaster mentioned above.

No joy is being sparked with the current behaviour. :joy:

[wli3]

Replied here https://github.com/dotnet/cli/issues/11259#issuecomment-487447234

(back to folding clothes)

[Shoh]

I don't understand why a flag can't be added, like it was suggested in dotnet/cli#11259, and just be done with it? It's not removing or changing any default behavior (so no users will be surprised) and it will satisfy the needs of all those that want the option to not throw an error when installing a tool that has already been installed. Using dotnet update is NOT a proper solution for it. What if I don't want to update a tool every time a new version is released? Because it's usually not a good idea to update right away for most things (for obvious reasons).

Please just add the flag and be done with it so we can all continue with our work.

[wli3]

@Shoh i hope to understand your scenario better. You do not want to update to the latest version, but if according to your suggestion, with the new flag, the dotnet install will still install the latest version.

We added "--version" option to dotnet tool update (in 3.0.100 preview). If you want to pin to an older version, will always run "dotnet tool update mytool --version PINNED_VERSION" works?

[wli3]

I created https://github.com/dotnet/cli/issues/11494 to discuss this specific option

[Shoh]

My use case (and I'm sure for many others) is for CI scripts. I should be able to put dotnet tool install (inserttoolhere) and not worry about it failing on subsequent builds. IMO, it doesn't feel right to use update when you're actually looking to just install a specific version.

Since the current behavior is to fail with exit code 1 when a tool is already installed, IMO, the safest solution is to add a flag to disable the "exit with error if tool is installed" behavior for users that opt to use the flag.

I thought either of the suggestions that were in dotnet/cli#11259 were fine (--slient|-s or --no-errors|-ne) but I'd be okay with something like --skip-installed.

[Shoh]

I will say that I agree with the others though, that the current behavior is not _normal_ behavior and "gracefully failing" (i.e. exit with code 0 if already installed) should be the default behavior. If anything, the current behavior should be "opted" in, if a user wants it. i.e. something like dotnet tool install sometool --error-if-installed

I was just providing an option to satisfy the needs of those that want _normal_ behavior without breaking or surprising any users that have gotten used to or have some reason to prefer the current behavior.

I am personally okay with including a flag to get the behavior that I want but I would prefer the current behavior to be "fixed" to something more normal. (If that was an option on the table) Again, ultimately, I'm okay with whatever is decided is best for the majority.

[chrisgilbert]

This broke our makefile, which tries to install 4 tools so we can use them to do various things - lambda, cake, and unit test coverage for an AWS lambda project we have.

If any one of the tools are installed, it will exit with a failure, and not install the rest (that's the normal behaviour of make).

That's not expected behaviour to me - I went searching for a way around it, and found this issue.

Since there's not a flag to change behaviour, to fix it we would either have to parse the exit text (maybe what I'll choose), or just ignore failures for any reason, and carry on with the rest of the installs (not ideal).

I can't presume exit code 1 is "success" though, because that's what it gives for DNS lookup failure, unable to connect to a nuget server, etc too.

Here's our example Makefile:

install-dependencies:
        dotnet tool install --global Amazon.Lambda.Tools --version 3.2.3
        dotnet tool install --global Cake.Tool --version 0.33.0
        dotnet tool install --global dotnet-reportgenerator-globaltool --version 4.2.1
        dotnet tool install --global altcover.global --version 5.3.675

[dquist]

Ran into this problem literally the first hour of trying to set up a CI pipeline for my first .net core 3 project. This behavior is so... disheartening and is bad DX.

The added upgrade option is nice I guess, but it still downloads the tool every time making it impossible to utilize pipeline caching.

All I want to do is install the tool if it doesn't exist without having to download any extra binaries. Why does this have to be so complicated?

[rmsy]

Is there any chance this is going to be re-visited? It is a little ridiculous that dotnet tool install returns 1 when the tool already exists. At the very least, would you consider adding a flag as proposed in #10242? This is inconsistent with the behavior of every other package manager out there, that I know of at least.

[gravufo]

How many people will have to complain here for Microsoft to stop burying its head in the ground and scream that everything is fine?

Edit: I saw that dotnet tool update was changed to have the kind of behavior we are expecting here. In my opinion, Microsoft still has it completely upside down. How does it make sense for a command called update to install if the tool doesn't exist whereas the install command fails if the tool already is installed??

[kylecooleylba]

Posting here because I agree with above comments should at least have a flag to return 0 if installed

[zoechi]

Makes it a pain in ansible

[rmsy]

@gravufo The dotnet tool update command "uninstalls and reinstalls a tool, effectively updating it." That is quite a joke and definitely not what an idempotent install command should do, so even that command can't serve as a proper substitute. The reality is that dotnet tool install should be a graceful no-op if the tool is already installed (as everyone here seems to agree, except for MSFT), and dotnet tool update should only update if there is a newer version determined to be available (but that's a different issue for a different thread).

[eocern]

Excuse me @wli3 did I miss a statement why "dotnet install" can not return 0 if tool is already installed ?

[andersjonsson]

I agree with everyone that this is a weird and unexpected behavior.
Using dotnet update works and solves the problem but it's not an obvious thing. It sure isn't a "pit of success".

I just encountered this error on our CI-machine and had to google for a solution.