Design for `dotnet tool update --all`

[JL03-Yue]

per issue #19650

I observed that the original issue reporter has shared a feature with similar functionalities here. The implementation appears thought out, and there's an opportunity to standardize the format further to align with the current structure of the dotnet tool. This effort is commendable and serves as both great work and a source of inspiration.

Ideas for dotnet tool update --all option

For global tools

Acquiring the list of dotnet tools
It is able to use dotnet tool list -g command to acquire the list of global tools installed. Since it is of the following format, it is able to read in the list of packageIds in the first column.

Updating the list of dotnet tools
After getting the list of dotnet tools, it might be able to use dotnet tool update [packageId] -g using DotnetCommand or other command executors.

For local tools

Acquiring the list of dotnet tools
Similar to global tools, It is able to use dotnet tool list --local command to acquire the list of local tools installed. Local tools has 4 columns and should read in the list of packageIds in the first column.

Updating the list of dotnet tools
After getting the list of dotnet tools, it might be able to use dotnet tool update [packageId] using DotnetCommand or other command executors.

[JL03-Yue]

Updated design ideas: Huge thanks from the clarifications from @baronfel

• Behavior of the dotnet tool update --all positional arguments:

Currently, the dotnet tool update option requires arguments. To accept --all without positional argument, the design ignores the positional arguments if --all is specified to ensure consistency and add flexibility.

• Separation of global and local update for --all:

There is a consideration whether global and local tools should be combined or separated when utilizing the "--all" option. Given the different nature for global and local tools, combining them could streamline commands but may lead to ambiguity or unintended consequences. Here we separate global and local tools when using the --all option for user distinction and more targeted actions.

• Orchestration: CLI Commands vs. Code for dotnet tool update

There is a choice between using CLI commands or dotnet tool update code for orchestration tasks. CLI commands are simple, but may lack error handling and flexibility in handling complex scenarios. Here suggested is to use code-based orchestration for better error handling and detection of edge cases.

[JL03-Yue]

Updated design ideas and ToDo items: Huge thanks to @dsplaisted

• The testing logic for -all option and optional packageId. The testing logic for required packageId without -all.
• Tests for update multiple tool package at once with --all option in command. Existing tool package includes global.tool.console.demo and global.too.console.demo.with.shim. Mock for global and local test environment might be needed.

[baronfel]

we have -all now! closing this as a result.