Integration with GenericHost

[haefele]

Are there any plans on how to integrate this with the GenericHost from Microsoft.Extensions.Hosting?

I mean all the functionality the GenericHost provides like the hosting environment, logging, DI, configuration - would still be useful when creating a command-line API.

I saw that you can add your own registrations to the BindingContext.ServiceProvider - but I'm not quite sure if that's the right way to integrate the GenericHost with this library.

[jonsequitur]

It's been brought up a couple of times but not looked at closely. The service registration in BindingContext is still a work in progress. How might you imagine the integration working?

[loic-sharma]

@natemcmaster's fork of CommandLineUtils has integration with generic hosts: https://natemcmaster.github.io/CommandLineUtils/docs/advanced/generic-host.html

The highlights are:

1. There's an extension method on IHostBuilder to run the command line app
2. Dependency injection works with the command handlers

[fredrikhr]

I concluded in #533 that adding the generic can neatly be done as an Invocation Middleware. This means that command-handlers can accept parameters of type IHost and continue from there. E.g. a handler can get the Host DI-container from the IHost.Services property. This becomes especially nice when using the Host.CreateDefaultBuilder() factory method coming in Microsoft.Extensions.Hosting version 3.0 (currently in preview).

Actually there are some things to be said for separating the command-line parser services from the host. Take a look at #533 where I have done that, but provided the ability to bridge that separation if necessary.

The approach is similar to how the generic host separates host configuration and app configuration. I.e. the generic host actually first builds a Configuration for the host, and then injects that into the application DI-container. I create the Host and start it, and then add it to the invocation binding context.

If you do the Generic Host as a command-line invocation middleware, you still get the benefits of being able to do --help short-circuiting different behaviours depending on commands, etc, and it does so without having to jump through too many hoops.

[alexdresko]

@couven92 Now you just have to get your branch to pass the CI build. :)

[haefele]

@couven92 That is basically what I ended up doing as well - just not as well organized. Good job! 😄

[fredrikhr]

#533 is now merged, so now you can use UseHost to very easily and conveniently make use of the Generic Host. This will become even better if you use the Host.CreateDefaultBuilder method from the 3.0.0-preview5-* version of the Microsoft.Extensions.Hosting package on NuGet.

[alexdresko]

@couven92 Besides using .NET Core 3, and the latest command line nuget packages, what code changes need to be made to the generic host sample app for this integration to work?

I tried to figure it out on my own, but ran out of time. I'm a little confused about what to do.

[fredrikhr]

@alexdresko checkout https://github.com/couven92/dotnet-command-line-api/tree/hosting-sample/samples/HostedConsole for a small example using .NET Core 3.0 together with the new hosting API.

Or checkout using the following git command

git clone --depth 1 --branch hosting-sample https://github.com/couven92/dotnet-command-line-api.git -- couven92-dotnet-command-line-api

And navigate to the samples/HostedConsole subfolder, or simply open up the Solution.

[fredrikhr]

Note that System.CommandLine.Hosting also works with .NET Core 2.2. You'll just have to go through the pain of configuring the host yourself instead of being able to use the awfully convenient Host.CreateDefaultBuilder. Although, on the other hand, using Microsoft.Extensions.Hosting version 2.2.0 (which targets .NET Core 2.2) has a much smaller dependency graph exactly because it does not add anything to the HostBuilder.

[EugeneKrapivin]

After going down the rabbit hole, it seems that the UseHost method (which doesn't support the Host.CreateApplicationBuilder(args); host builder out of the box) still doesn't really use the DI container built by the host, from what I understood I have to inject the IHost into the command and use service provider to locally resolve dependencies.

Will you tackle this matter as part of #2341?

Back story:
I'm playing around with an internal CLI tool which needs the Host (I'm using http factories, access token management, telemetry, multiple background services, channels) and I failed to find a community best practice to build commands which leverage the Host DI. I eventually resorted to building a custom pattern of command classes which get DI resolved in an IHostedService, with which I build up the RootCommand using closures to capture the command class which got all it needs injected from the Host DI. This whole approach seems a bit... yucky to be frank :D

Once you have real tight integration with Generic hosts System.CommandLine would be the first CLI toolkit to do so.

[fredrikhr]

I (the original author of System.CommandLine.Hosting) am currently looking into how to best support Host.CreateApplicationBuilder.

What you need to do is first acknowledge that command line argument parsing happens before the IHost is created. Therefore, CliCommand creation and parsing cannot be part of the Host DI system.

Instead you'll use the parsing result from System.CommandLine to feed into Options instances used by the IHost application like you're used to. But instead of binding from a json file, you bind from the ParseResult. For simple scenarios, there is an extension method BindCommandLine() on the OptionsBuilder.

Lastly, you'll want to use CommandHandler.Create in the assignment to your CliCommand.Action property. As an argument to create use a delegate with one argument of type IHost.

If you're using hosted services, the IHost should automatically start your service when your command handler is invoked. In that case simply call host.WaitForShutdown in your handler.