[WIP] dotnet tool exec <package[@version]> one-shot execution

[edvilme]

Closes #31103

WIP: Name, and implementation may change

[marcpopMSFT]

Commented offline that we wanted to start with "dotnet tool run --from-source". We're currently discussing alias options or auto-detection options but the full command is safest to start with.

[dsplaisted]

@edvilme I would recommend patterning this more off of local tools than global tools. Global tools download the packages to a folder structure under .dotnet\tools\.store\, and also download it to a staging folder before copying it to the final location. An executable shim is also created or copied to the global tools folder.

Local tools on the other hand run directly from the packages in the NuGet global packages folder. I think it would be easier to run a tool from there without any side effects besides the fact that the package is now in the global packages folder.

[nagilson]

Things to consider for review when it is finished / good test cases:

• Does it delete the tool, as it says without permanently installing it
• It passes the args to tools
• Version resolution works
• Uses latest if no version specified
• It uses the feed
• Make sure we prompt before downloading something new
• Does it have -y -n
• Supports nuget feed options

I like dotnet toolx personally but ok to see why we are using --from-source for now since it matches the other patterns.

[edvilme]

/ba-g stuck

[marcpopMSFT]

Note: Ready for review, failing some test.

[Forgind]

The core functionality here looks good to me, but there are several cleanup things I noticed as I was reviewing. Great work!

[Forgind]

Why do we have to define these here as opposed to just adding ToolInstallCommandParser.RollForwardOption in ToolExecuteCommandParser.ConstructCommand and using that in the Command?

[marcpopMSFT]

I fixed the issues flagged in the PR review from forgind and did some local testing.

Testing done:
Example command: dotnet tool exec dotnetsay --version 2.1.* --source https://api.nuget.org/v3/index.json -- hello from dotnetsay

• version
• version with a .*
• @ version
• --source
• --add-source
• --ignore-failed-sources
• --yes
• tool parameters

Testing I haven't done:

• --configfile
• --prerelease
• --interactive
• --verbosity

I didn't review the code or the automated tests yet.

2 issues identified:

1. I had to check the package id was null even though System.CommandLine already does (because of nullable enabled) that so currently there is a graceful error that I don't think will ever be hit. Suggestions?
2. It reports the tool is not found on the system even though it's already in the nuget cache. Need to investigate.

[baronfel]

I had to check the package id was null even though System.CommandLine already does (because of nullable enabled) that so currently there is a graceful error that I don't think will ever be hit. Suggestions?

dotnet/command-line-api#2564 went into S.CL last week that you're intended to use for this scenario - kind of a marker that "trust me bro, I know what I'm doing"

[Forgind]

This still seems unused.

[dsplaisted]

Fixed in follow-up PR: #49329

[Forgind]

tiny nit:

Suggested change

	<data name="ToolRunArguementsDescription" xml:space="preserve">
	<data name="ToolRunArgumentsDescription" xml:space="preserve">

[dsplaisted]

Fixed in follow-up PR: #49329

[dsplaisted]

I've created a new PR to continue work on this, so I'm going to close this one.