Add generic host builder pattern for System.CommandLine.Hosting

[NikiforovAll]

Align System.CommadLine.Hosting model with the way ASP.NET Core uses Generic Host.

It should be possible to configure CommandLineBuilder like this:

public static IHostBuilder CreateHostBuilder(string[] args) =>
    CommandLineHost.CreateDefaultBuilder(args)
        .ConfigureAppConfiguration((hostingContext, config) =>
        {
        })
        .ConfigureCommandLineDefaults(cmdHost =>
        {
            cmdHost.ConfigureServices(services =>
            {
            })
        })
        .ConfigureCommandLineBuilder(cmdBuilder => // CommandLineBuilder
        {
           cmdBuilder.UseReflectionAppModel(); // e.g. https://github.com/KathleenDollard/command-line-api-starfruit 
        });
    });

[shaggygi]

Would be nice to make it easier to use the Worker Service, as well. Referencing #556.

[NikiforovAll]

@shaggygi I think this solution allows it, because ParseResult is added as Singleton, so you can consume it from Worker.

Currently, it is not documented though.

[KathleenDollard]

You all will teach me a good bit on this, so let me start with what might be a simple question.

When generic host is in place, does it make sense to have the CommandLine Host on the stack, or (at least as an option) can we put the results in an instance (from StarFruit) available via DI ad then step out of the way.

(Question is based on current assumptions about how GenericHost works)

[NikiforovAll]

@KathleenDollard
It is definitely useful to be able to build DI container based on parsing results.
Also, there is already a method to use System.CommandLine.Binding.ModelBinder<T> binder:

services.AddOptions<MyAppOptions>()
    .BindCommandLine();
// source: src\System.CommandLine.Hosting\HostingExtensions.cs:70

Although, it introduces a cyclic dependency between CommandLineHostBuilder and CommandLineBuilder because:

1. Presumably, we want the next services InvocationContext, IConsole, IInvocationResult, ParseResult to be available during host configuration. (It is up to debate what services should be provided, but I mentioned services used in the current implementation.)
2. Currently, it is only possible to add IHost service to invocationContext.BindingContext outside of UseMiddleware method. In order to trigger middleware, we need to trigger commandLineBuilder.Build().InvokeAsync.

---

The current implementation gets around this by making IHost host = hostBuilder.Build() a part of the middleware, so InvocationContext is available from the middleware context.

[jonsequitur]

Can the patterns we use here be generalized to include IWebHostBuilder? The goals are the same it seems: #916.

[NikiforovAll]

Unfortunatelly, IWebHostBuilder doesn't implement IHostBuilder directly. It should be possible to migrate to generic host.

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureCommandLineBuilder(cmdBuilder => // CommandLineBuilder
        {
           cmdBuilder.UseReflectionAppModel(); // e.g. https://github.com/KathleenDollard/command-line-api-starfruit 
        });
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.UseStartup<Startup>();
        });

[jonsequitur]

To the extent that the patterns are similar, it would be good to have approaches and matching code for both, even if it means we need another project.

[KathleenDollard]

Aarrgh. Seems like an understanding of why IWebHostBuilder and IHostBuilder differ would be a starting point.

I don't yet see why multiple projects help over other approaches.

[jonsequitur]

They'll have different dependencies and you won't want the union of the two dependency graphs.

[jonsequitur]

I think a more inverted model, and doing away with the concept of a CommandLineHost, might align well to the existing host models, which would give us something like:

// Generic host:
new HostBuilder()
    .ConfigureCommandLine((CommandLineBuilder cmdLineBuilder) =>
    {
        cmdBuilder.DoStuff();
    })
// Web host:
new WebHostBuilder()
    .ConfigureCommandLine((CommandLineBuilder cmdLineBuilder) =>
    {
        cmdBuilder.DoStuff();
    })

[NikiforovAll]

@jonsequitur

1. Could you please describe the use case of ConfigureCommandLine in the case of WebHostBuilder:IWebHostBuilder. How is it going to be consumed and what services should be added to DI?

For configuration purposes next methods are used:

new HostBuilder()
    .ConfigureHostConfiguration(config => config .AddCommandLine(args))
    .ConfigureAppConfiguration((hostingContext, config) => config.AddCommandLine(args));
// Microsoft.Extensions.Hosting.IHostBuilder ConfigureHostConfiguration
// Microsoft.Extensions.Hosting.IHostBuilder ConfigureAppConfiguration

Please see: comment above

2. There is another aspect of ConfigureCommandLine that could be host-dependent. Mainly, at what point of time parseResult.InvokeAsync() is executed. What do you think, how should it be organized?
   In Add generic host builder pattern [WIP] #919, I've added CommandLineExecutorService that shuts down IHostBuilder after command execution.

services.AddHostedService<CommandLineExecutorService>()

3. I agree that CommandLineHost might be a dubious concept to follow.
   It is just something similar to WebHost.CreateDefaultBuilder. A factory to create IHostBuilder = Host.CreateDefaultBuilder(args) + cmdBuilder.UseDefaults().

---

I apologize for so many questions. It is quite an interesting bit of functionality to me.