Command.Create should not transitively depend on hard coded paths

[cdmihai]

The resolution of commands depend on Directory.GetCurrentDirectory() and AppContext.BaseDirectory(). This introduces an implicit dependency between command resolution and the process that requests it (basedirectory) and the root process that spawned everything (getcurrentdirectory).

Instead, these paths should be variables resolved / injected at runtime.

This change enables:

• decoupling command resolution from process identity
• increased testability of the command resolution algorithm (can setup a fake environment and assert for resolution outcome)
• calling verbs in-proc and out-of-proc

[TheRealPiotrP]

@cdmihai do you have a proposed design? I'd like to see how it would impact UX for the product.

[cdmihai]

I don't think this would impact the user. The change suggests replacing the hard coded paths from below with parameters, that would probably get sent to TryResolveCommandSpec and then trickled down (or maybe transform CommandResolver into a non static class whose instances get constructed with them)

• https://github.com/cdmihai/cli/blob/8274f5285b4dd45ab73e12e26033d3428457de5e/src/Microsoft.DotNet.Cli.Utils/CommandResolver.cs#L72
• https://github.com/cdmihai/cli/blob/8274f5285b4dd45ab73e12e26033d3428457de5e/src/Microsoft.DotNet.Cli.Utils/CommandResolver.cs#L35

That would make the CommandResolver quite configurable (good for writing tests that send funky paths, good for build to ensure the command is resolved as it would have been by Compile, etc)

[baronfel]

This is no longer applicable to the parser now that we're on System.CommandLine.