Improve dotnet tool install/update experience

[lunim]

For the purposes of build automation, it would be helpful for 'dotnet tool install' to either update or return a positive exit code if the tool is already installed. Likewise, 'dotnet tool update' might install the tool if not already installed.

We are basically looking for a clean way to ensure a global tool is installed and updated at runtime, preferably with a single command. It seems most error code responses are 1, so it is difficult to determine what the error is.

Some examples of current behavior:

dotnet tool install dotnet-mytool -g
Tool 'dotnet-mytool' (version '1.0.0') was successfully installed.

Then, when running with version 1.0.1 available of the same tool:

dotnet tool install dotnet-mytool -g
Tool 'dotnet-mytool' is already installed.

If I try to run update without the tool installed:

dotnet tool update dotnet-mytool -g
Tool 'dotnet-mytool' is not currently installed

One potential flow that would be useful:

dotnet tool install dotnet-mytool -g
Tool 'dotnet-mytool' (version '1.0.0') was successfully installed.

(new tool version published)

dotnet tool install dotnet-mytool -g [possible flag to enable behavior]
Tool 'dotnet-mytool' was successfully updated from version '1.0.0' to version '1.0.1'.

dotnet tool install dotnet-mytool -g
Tool 'dotnet-mytool' is already installed and is the latest version [code 0, currently returns a 1]

[livarcocc]

If this is for CI, should you be installing the tool globally?

For CI, I would imagine you would want to use the --tool-path option to install the tool in a location under your repo, that the CI machine could then clean up after the build has run. This way, you would have complete control over which global tools are being used by your build.

[livarcocc]

cc @KathleenDollard @peterhuene @wli3

[lunim]

@livarcocc I think we could make it work with the --tool-path option, since our build environment should be clean each run.

It would still be nice for a single command install/update, we have some other tools planned for end-users for their development machines. The experience would be much cleaner if they can just run a single command to ensure they have installed and are running the latest version.

Thanks!

[wli3]

It is good for usability. However, the advantage of explicit and strict is the state transition is narrow. It is easy to understand and control action.

With update has implicit install, update will have different action depends on the disk state.

maybe update --ensure-install is a better alternative. I prefer explicit than overload a term.

[KathleenDollard]

I'm fine using update for this. We need to work on the switch name.

[dasMulli]

update --install could be enough (saving keystrokes over --ensure-install), similar to git submodule update --init instead of submodule init + submodule update.

[livarcocc]

@KathleenDollard and @wli3 please reach out an agreement on what the experience should be here and update this document with the changes we are going to make.

[wli3]

@KathleenDollard
We had a one key problem before. Define update, especially when there are multiple feed. After talking to nuget team, we can rely on simply compare version is bigger.

[KathleenDollard]

What syntax are we currently planning? I assume this is what we want to recommend for CI where the version number should roll forward.

[wli3]

Please continue comment this issues if you think dotnet/cli#10205 cannot solve the problem of your scenario and I will reopen it

[dquist]

For CI, I would imagine you would want to use the --tool-path option to install the tool in a location under your repo

Except that using --tool-path still results in an error code if you utilize pipeline caching. This is not a solution.

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?