Add flag to override default tool install behaviour when tool already installed

[sandcastle]

Currently, running the install command for a tool that is already installed returns an error. This is a real pain when using this in dev and CI scripts as it will abort the script. I.

Ideally, it should be an idempotent operation and not raise any error like like installing NPM, Yarn, Nuget and many other package managers. But given #9500 was closed and there appears to be no appetite to change the default, can we at least get a flag added to override the behaviour?

Steps to reproduce

1. Already have the dotnet-format
2. Run dotnet tool install -g dotnet-format
3. You will get an error

New flag

Adding a --slient|-s or --no-errors|-ne flag would work:

dotnet tool install -g --slient dotnet-format
dotnet tool install -g -s dotnet-format

Running the following would not raise an error:

dotnet tool install -g -s dotnet-format
dotnet tool install -g -s dotnet-format

Example dev/ci script

Here is an example of a script that would currently blow up:

#!/bin/sh
set -e

cd "$(dirname "$0")/.."

# --------

echo "Installing dependencies"
if [ "${1}" != "--ci" ]; then

  # Error will occur here!
  dotnet tool install -g dotnet-format

fi

dotnet restore

Environment data

dotnet --info output:

.NET Core SDK (reflecting any global.json):
 Version:   2.2.104
 Commit:    73f036d4ac

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.14
 OS Platform: Darwin
 RID:         osx.10.14-x64
 Base Path:   /usr/local/share/dotnet/sdk/2.2.104/

Host (useful for support):
  Version: 2.2.2
  Commit:  a4fd7b2c84

.NET Core SDKs installed:
  2.2.104 [/usr/local/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.2.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.2.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.2.2 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Please let me know if this is something you would like to see a PR for?

[wli3]

Could you check if "dotnet tool update -g"'s behavior is enough for this situation.
After this change dotnet/cli#10205, it will not error when it is not installed and if you run update multiple times it will not fail.

[BenjaminAbt]

Hi @wli3 I agree to https://github.com/dotnet/cli/issues/9482#issuecomment-432336340 in https://github.com/dotnet/cli/issues/9482

The behaviour of the dotnet cli here is absolutely insufficient and does not adhere to any common convention.

If I use a Hosted Agent in Azure DevOps, then I can simply use dotnet tool install command, because I always have a greenfield and can install the tool.
If I use a custom agent in Azure DevOps I have to install the tool first (manually!!!!) and then use dotnet tool update.

I can't use the dotnet install command, because the second call throws an error that it is already installed.
Nor can I use the dotnet update command consistently, because if nothing is installed at all, there is also an error.

This is a very inconsistent behavior of the CLI and absolutely not what I expect.

Sample Hosted Agent

- script: dotnet tool install GitVersion.Tool --version ${{ parameters.gitVersionVersion }} --tool-path ${{ parameters.toolPath }}/gitversion --configfile ${{ parameters.dotnetInstallConfigFile }}
  displayName: GitVersion - Install/Update

Sample Custom Agent (you have to install the tool first manually)

- script: dotnet tool update GitVersion.Tool --version ${{ parameters.gitVersionVersion }} --tool-path ${{ parameters.toolPath }}/gitversion --configfile ${{ parameters.dotnetInstallConfigFile }}
  displayName: GitVersion - Install/Update

With 3.0 you have a great opportunity to fix this uncommon behavior.

[wli3]

Nor can I use the dotnet update command consistently, because if nothing is installed at all, there is also an error.

This behavior will change to "install when not present", as commented above. Does that solve the issue?