Add a one-shot execution mode for .NET tools a la npx

[baronfel]

Is your feature request related to a problem? Please describe.

Currently to use a .NET global tool that may or may not be installed, you need to perform a series of steps

• install the tool globally
• ensure the global tool install directory is on the PATH
• invoke the tool
• (optionally) remove the tool

And for local tools, you need to

• create a tool manifest
• install the tool
• invoke the tool
• (optionally) remove the tool

When all you really want to do is

• invoke the tool

We should consider adding a mode of running a .NET tool that combines all of these steps into one user-facing step.

Describe the solution you'd like

Something akin to

dotnet toolx [-g|--global] [--rm] [--version toolVersion] <toolName> [tool args and options]

that would combine all of the preceding steps into one logical command. The tool would be installed (locally by default, creating a manifest if necessary), executed passing along whatever args, and then optionally being uninstalled after execution. If a version was supplied and the locally-available version of the tool (if any) doesn't satisfy that version, the specified version would be installed.

Additional context

Add any other context or screenshots about the feature request here.

[baronfel]

Requirements

• There should be one command to install, execute, and clean up a tool
• There should be no artifacts on the PATH or other user system side effects as a result of using the new command
• If a tool is run without any version, the latest version available on the configured feeds should be used
• For performance, if the tool version is already downloaded locally, the local download should be used
• For security, we should prompt before downloading a package that doesn't exist locally
  • We should accept a -y/-n style argument to prevent blocking
• For security, we should allow users to use the existing NuGet source-management commands to manage the feeds that are used to do version-searching and package downloads
• The happy path should be to do the most recent, awesome thing possible in the absence of any CLI args overriding that choice
  • latest version
  • most recent TFM/arch
  • quietest verbosity
  • etc

CLI Interface

In general, we should reuse as many relevant flags from the existing tool install commands as possible.

Keep

• --version (though this is maybe not required if a user uses the package@version syntax)
• --configfile (for controlling NuGet configuration)
• --add-source / --source (for controlling NuGet feeds)
• --verbosity (all commands should support verbosity)
• --prerelease (allow using prerelease packages when no version is provided)
• --ignore-failed-sources (though for usability we could assume this by default)
• --interactive (though this is on by default in newer SDKs)

Consider

• --allow-roll-forward (we may want to do this by default for toolx)
• --framework (which TFM to use - we should use TFM of the current SDK)
• --arch (we should use the arch of the current SDK)

Ignore

• --create-manifest-if-needed
• --allow-downgrade
• --disable-parallel
• --no-http-cache
• --global
• --local
• --tool-path
• --tool-manifest-path

Process

When a user runs dotnet toolx fsautocomplete, we should

• check the feed configuration and scrape the feeds for the latest version of fsautocomplete
• see if that package is available in the configured global package caches
  • if so, invoke the fsautocomplete tool
  • if not, download that package from the configured feeds, then invoke that tool

Invoking the tool

There are two main alternatives here

• dotnet-based invocation
• apphost invocation

They have their pros and cons. If we do dotnet-based invocation then there's less work to do and we don't have to worry about where to store the apphosts to prevent cluttering PATH, etc.
If we do apphost-based invocation then users may get a clearer chain of responsibility - you can see the apphost, etc.

[timheuer]

what about --skip-failed-sources I feel this always trips up some scenarios if we don't think about it

[baronfel]

@timheuer --ignore-failed-sources is one of the ones we'd keep, yeah. It's in my 'Keep' list :)

[nagilson]

I would support adding a 'latest' option if you go the path of preferring local (any version) -> global (any version) -> downloading (latest) to the temp folder (cached), if no version is specified. I would also support adding a version and respecting that, as well as doing tool@version.

[nagilson]

Shorthand suggestions from @dsplaisted: dnx or dntx

[dsplaisted]

Have we thought about how to treat the difference between the tool package name and the command name? I think it's common for those to be different, for example:

Package Id                        Version         Commands
--------------------------------------------------------------------
microsoft.dotnet-interactive      1.0.415202      dotnet-interactive
powershell                        7.5.0           pwsh

Today, you use the package name to install the tool, but the command name to invoke it. How should we handle this with one-shot execution mode?

@baronfel @edvilme

[edvilme]

Have we thought about how to treat the difference between the tool package name and the command name? I think it's common for those to be different, for example:

Package Id                        Version         Commands
--------------------------------------------------------------------
microsoft.dotnet-interactive      1.0.415202      dotnet-interactive
powershell                        7.5.0           pwsh

Today, you use the package name to install the tool, but the command name to invoke it. How should we handle this with one-shot execution mode?

@baronfel @edvilme

The way it currently works on my pr is like that. We use the package name to install, and the command name (retrieved from the package data) to execute.
However, since this is still the dotnet tool run command, I see why people would be confused to put in the package name instead of the command

[baronfel]

There are a few options:

• if the package contains only a single tool, then invoke that tool
• do like npx does and provide a way to specify the package and command separately: npx --package=<name[@version]> <cmd> <args>