Provide CommandContext in DI

[wayneyaoo]

This is what I do:

        var containerBulder = new ServiceCollection();
        // inject stuff via containerBuilder
        // ....

        var container = containerBulder.BuildServiceProvider(
            new ServiceProviderOptions()
            {
                ValidateOnBuild = true,
            });
        app.UseMicrosoftDependencyInjection(
            container,
            argumentModelResolveStrategy: ResolveStrategy.ResolveOrThrow,
            commandClassResolveStrategy: ResolveStrategy.ResolveOrThrow);

During the injection process, it'd be much helpful to be able to access the CommandContext to configure some dependency before injecting to the container, based on the context, e.g., options that are passed in. Is there anyway we can achieve this? This is what System.Commandline does btw.

I'm currently using ParameterResolver to work around this, which has access to context but it's weird. Is there any recommended way to do this?

[drewburlingame]

It's not something the framework explicitly supports at the moment. There is a runInScope delegate you could use to create the scope that gives access to the CommandContext. I would need to do a little research to see how to make it available in the registration methods. If you know how to do it or have examples, I'd be interested in adding it or accepting a PR for it.

[wayneyaoo]

Are you saying something like this...?

        app.UseMicrosoftDependencyInjection(
            container, // where is my container?
            argumentModelResolveStrategy: ResolveStrategy.ResolveOrThrow,
            commandClassResolveStrategy: ResolveStrategy.ResolveOrThrow,
            runInScope: context =>
            {
                var builder = new ServiceCollection();
                // inject stuff with context
                // Inject other dependencies
                return builder.BuildServiceProvider();
            });

But where is the container if it gets built inside the callback? If I should build dependency outside of the callback, then what should I return as IDisposable?

I haven't looked too deep into the source but I used System.Commandline a bit before. The way it does it is that the container builder is accessible from middleware via Context, similar to your Services in the AppConfigBuilder but I'm not sure if it's the right place to look into. Here's an example in System.Commandline:

        var commandBuilder = new CommandLineBuilder(rootCommand)
            .CancelOnProcessTermination()
            .UseExceptionHandler(ExceptionHandler.Handle)
            .UseVersionOption()
            .UseHelp()
            .UseEnvironmentVariableDirective()
            .RegisterWithDotnetSuggest()
            .EnablePosixBundling()
            .UseParseErrorReporting()
            .AddMiddleware(DependencyInjectionMiddleware.Inject); // here. The inject is client code implementation.

...

    public static async Task Inject(InvocationContext context, Func<InvocationContext, Task> next)
    {
        context.BindingContext.AddService<IFileSystemOperation>(_ => new FileSystemOperation()); // my implementation

        await next(context);
    }

Though as you can see the injection is a bit weird because client code will need to specify how the dependency should be built, but this is something the team seems to be aware of and is working to improve. The point is, I can add something according to the context.

Do you think this is a way the Services can be "abused"?

[drewburlingame]

Do you think this is a way the Services can be "abused"?

I don't think so. The context is built after the container would be configured.

For some context, one of the goals is to support a REPL session, similar to entering a python or sql session in the console. It can be done today if someone wants to and I have a PR that builds in explicit support but I need to get time to write tests for it. There are a lot of tests to write for it.

To this point, there could be a lot of contexts in that case. What I think we'd need to do is create a ContextLocator that would return the context for the current scope and each context would get it's own scope. The container config would need to support the fact there could be multiple contexts. It could use something like (sp => sp.GetRequiredService()) to do the conditional logic.

[wayneyaoo]

: ) sorry I'm not following this... does it mean the runInScope is not ready to use? If not, could you please share an example on how this callback can be used?

[drewburlingame]

Think of CommandContext more like the HttpContext. HttpContext is created after the container is configured. The container can serve many requests. In the same way, the container in CommandDotNet could service many requests when run in REPL (aka interactive) mode where the app spins up and then waits for the user it give it commands. In that case, the container would need to be configured before the commands are generated.

runInScope can support that scenario as well. What it doesn't provide is access to the CommandContext. I think that could be added.

[drewburlingame]

What information would you be looking for in the CommandContext? As you can see from order the middleware is run below, BeginScope is the 4th step and is run in the PreTokenize stage. That is when runInScope will be executed if specified.

If we created a ContextLocator class and it was registered as scoped with the container, we could set the instance on the locator in that step. This is something you could do now by adding your own middleware step to run after the BeginScope step. Create the ContextLocator and register it with the container and then resolve and set it in the middleware step. You could then resolve that locator in your registration method and change what is returned accordingly. If it works for you, I'd accept a PR to enhance this framework with it.

Step	Stage	Order
MiddlewareSteps.DebugDirective	PreTokenize	0
MiddlewareSteps.CancellationHandler	PreTokenize	1000
MiddlewareSteps.OnRunCompleted	PreTokenize	2000
MiddlewareSteps.DependencyResolver.BeginScope	PreTokenize	3000
MiddlewareSteps.Help.PrintHelpOnExit	PreTokenize	4000
MiddlewareSteps.ParseDirective	PreTokenize	5000
MiddlewareSteps.Tokenize	Tokenize	0
MiddlewareSteps.CreateRootCommand	Tokenize	31767
MiddlewareSteps.ParseInput	ParseInput	0
MiddlewareSteps.TypoSuggest	ParseInput	1000
MiddlewareSteps.AssembleInvocationPipeline	ParseInput	2000
MiddlewareSteps.Version	ParseInput	30767
MiddlewareSteps.SetArgumentDefaults	ParseInput	31767
MiddlewareSteps.Help.CheckIfShouldShowHelp	ParseInput	32767
MiddlewareSteps.PipedInput	PostParseInputPreBindValues	0
MiddlewareSteps.ValuePromptMissingArguments	PostParseInputPreBindValues	31767
MiddlewareSteps.BindValues	BindValues	0
MiddlewareSteps.ResolveCommandClasses	BindValues	1000
MiddlewareSteps.ValidateArity	PostBindValuesPreInvoke	0
MiddlewareSteps.CommandLogger	Invoke	0
MiddlewareSteps.InvokeCommand	Invoke	32767

[wayneyaoo]

Thank you for the information! I'll see what I can do later with this table. btw this table is super helpful. Do you consider to add it to doc? I normally use debugger to see what the values is if I need to add to somewhere in the middle.

What information would you be looking for in the CommandContext?
I mostly need access to the token information, like if some options are set to create some infrastructural objects. e.g., if "--json" is specified, the IOuputConsoleFactory is configured to provide JsonOutputConsole, then the end command doesn't have to resolve the factory later (though this is indeed a common pattern).

I'm interested in a PR too. will see if I can get to this later.

[drewburlingame]

Do you consider to add it to doc?

I think I have a stash somewhere to get this into the help docs. I have it generated from a test so it should be easy enough to add to the docs using Verify to capture the output.