Inject CommandSettings or retrieve during/after run

[woutervanranst]

Use case (simplified):

• I'm registering a Azure Blob Container Client with accountname and accountkey which are passed as cli commands
• The CommandSettings are not available through dependency injection - hence I cannot have this client injected and must manually instantiate it in Execute(CommandContext ctx, CommandSettings settings) {} which defeats the purpose of DI somewhaat

Would there be an easy/elegant way to inject the parsed CommandSettings?
I feel something may be possible with an ICommandInterceptor and/or ITypeRegistrar.RegisterLazy (deferring the resolution until the command is fully parsed)?

Alternatively, is there a way where I could get the parsed CommandSettings after CommandApp.Run(args)? In that case I would set up a second ServiceCollection with the parsed CommandSettings, the container client, ... and go from there.

[nils-a]

@woutervanranst I'm not sure I get what you're aiming at. Are you trying to use the CommandSettings, not as part of the command being run, but rather later? Like after CommandApp.Run(args)?

[woutervanranst]

@nils-a, indeed - that is my alternate ask.

But preferred would be to get the CommandSettings available for DI (not just through an argument of Execute) during the CommandApp.Run()

[nils-a]

@woutervanranst I don't really see a non hacky way to achieve this. The only way I currently see is to inject your DI container in the command and then manually add the CommandSettings to the container to be resolved again at a later time.

[nils-a]

@woutervanranst I had an idea today:
You could register an instance of the settings in your DI container right from the start, having the command run will modify that instance, and when you retrieve it at the end you will have the settings reflect the commandline.

I tested this using the following code:

using Spectre.Console;
using Spectre.Console.Cli;

// build DI
var container = new SimpleInjector.Container();
var settingsInstance = new HelloCommand.Settings();
AnsiConsole.MarkupLine($"[gray]name before run: {settingsInstance.Name}[/]");
// register settings as instance.
container.RegisterInstance(typeof(HelloCommand.Settings), settingsInstance);

// run command
var app = new CommandApp<HelloCommand>(new SimpleInjectorRegistrar(container));
var result = app.Run(args);

// resolve settings again
var settings = (HelloCommand.Settings)container.GetInstance(typeof(HelloCommand.Settings));
AnsiConsole.MarkupLine($"[yellow]name after command-run: {settings.Name}[/]");
return result;

internal sealed class HelloCommand : Command<HelloCommand.Settings>
{
    public sealed class Settings : CommandSettings
    {
        [CommandOption("-n|--name")] public string Name { get; set; } = "Unknown";
    }

    public override int Execute(CommandContext context, Settings settings)
    {
        AnsiConsole.MarkupLine($"[gray]name inside command: {settings.Name}[/]");

        return 0;
    }
}

I'm using SimpleInjector here for DI, so your code might look a bit different for registering/retrieving.

[nils-a]

But wouldn't you need the concrete implementation anyway, when resolving the settings again from the DI?

[woutervanranst]

I could probably inject a class that has just

class CommandSettingsResolver
{
   public CommandSettings Settings { get; set; }
}

Set it in each Command and retrieve it after the Run(args) and with pattern matching retrieve the concrete type. Less hacky but I could live with it, unless you see another way?

[nils-a]

That would probably work, yes.

[woutervanranst]

The Interceptor is a pretty sweet way of solving it, avoiding DI and avoiding it needs to be implemented in each command:

internal class ParsedOptionsProvider
{
    public CommandSettings Options { get; set; }
}

...

var parsedOptionsProvider = new ParsedOptionsProvider();
var app = new CommandApp(registrar);
app.Configure(config => config.SetInterceptor(new CommandInterceptor(parsedOptionsProvider)));

...

internal class CommandInterceptor : ICommandInterceptor
{

    public CommandInterceptor(ParsedOptionsProvider op) => this.op = op;
    private readonly ParsedOptionsProvider op;

    public void Intercept(CommandContext context, CommandSettings options) => op.Options = options;
}

[jeffward01]

The Interceptor is a pretty sweet way of solving it, avoiding DI and avoiding it needs to be implemented in each command:

internal class ParsedOptionsProvider
{
    public CommandSettings Options { get; set; }
}

...

var parsedOptionsProvider = new ParsedOptionsProvider();
var app = new CommandApp(registrar);
app.Configure(config => config.SetInterceptor(new CommandInterceptor(parsedOptionsProvider)));

...

internal class CommandInterceptor : ICommandInterceptor
{

    public CommandInterceptor(ParsedOptionsProvider op) => this.op = op;
    private readonly ParsedOptionsProvider op;

    public void Intercept(CommandContext context, CommandSettings options) => op.Options = options;
}

Thanks for this!

If I am correct, this only works for 'before' the run. Such as:

• User executes cli command
• Interceptor does work...
• Target command executes
• End

Is there a way to replace 'End' with an interceptor? I am thinking I might need to use CommandDotNet to accomplish some of these advanced features? Honestly, i'd rather only use Spectre.Console as I am very familar with Spectre.Console