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

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 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.

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.

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

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

@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).

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?

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??

This is unintuitive This is also undocumented (https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-tool-install) This is universally rejected by MS customers in this thread This is telling you that we don’t need separate install/update commands This is telling you that in CI/CD world we want UPSERT everywhere and parameters for version targeting etc

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.

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. 😂

As an update, we’re thinking of changing the install behavior so that it will not fail if the tool is already installed. This will mean that dotnet tool install will pretty much work the same way dotnet tool update already does. Because of that, over time we might deprecate dotnet tool update.

We would likely add options to allow the old behavior, for example something like --fail-if-already-installed and --update-only.

dotnet tool install -g <tool> | echo "already installed"

@cliffchapmanrbx and others participating in this issue, you should upvote the issue https://github.com/dotnet/sdk/issues/10310 which is similar and is currently open.

Using .NET Tools in a CI pipeline is currently painful and requires a lot of scripting to handle errors, which should be handled by dotnet tool directly.

I suggested a couple of different approaches that could help. Adding a flag would improve the UX by a lot:

dotnet tool install toolname --ignore-if-installed

If changing the install command is breaking and not possible, creating a dedicated ensure command could work:

dotnet tool ensure --local toolname --version toolversion

Expectations:

• If the command does not specify version, the latest version is installed. Exit code = 0
• If the command specify version 2.0.0 and tool 2.0.0 is already installed, do nothing. Exit code = 0
• If the command specify version 2.0.0 and tool 1.0.0 is already installed, upgrade to 2.0.0. Exit code = 0
• If the command specify version 2.0.0 and tool 3.0.0 is already installed, downgrade to 2.0.0. Exit code = 0

More details:

• https://github.com/dotnet/sdk/issues/10310#issuecomment-757602576
• https://github.com/dotnet/sdk/issues/15254#issuecomment-780309601

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.

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.

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

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.

Makes it a pain in ansible

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.

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!

That is good news @dsplaisted !

Expectations of future behavior that I believe most agree on:

• dotnet tool install without a --version specified will try to update to the latest version when the tool is already installed, return 0 exit code if latest version already installed or if upgrade is successful, 1 otherwise

• dotnet tool install with a --version specified will try to upgrade or downgrade to the specified version when the tool is already installed but with a different version than specified, return 0 exit code if specified version already installed or if upgrade or downgrade is successful, 1 otherwise

dotnet tool install -g <tool> | echo "already installed"

That’s brilliant. Except I changed the echo output to “dotnet install is dumb”

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

@dsplaisted @riverar Following the principle of deterministic builds, if the --version is present it means my process expects that particular version every time it runs, consistently.

Thus, I’d argue that should be the other way around e.g. A --do-not-downgrade option, which would prevent a downgrade when a higher version is already installed.

edit: Also, the name of the option is --version… If option were called --minimum-version, then sure… I’d agree a downgrade would have to be --forced