How to integrate with .NET Generic Host?

[gitfool]

I'm toying with how to integrate Spectre.Console.Cli and .NET Generic Host with something like the following extracts:

public static class Program
{
    public static Task<int> Main(string[] args) =>
        HostRunner.Run(Constants.AppName, args, args => CreateHostBuilder(args).Build().RunAsync());

    private static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureAppConfiguration(args)
            .ConfigureServices()
            .UseSerilog(Constants.AppName);
}

public static IHostBuilder ConfigureServices(this IHostBuilder hostBuilder) =>
    hostBuilder.ConfigureServices((_, services) =>
    {
        services.AddHostedService<PulumiService>()
            .AddSingleton<ICommandApp>(_ =>
            {
                var app = new CommandApp();
                app.Configure(config =>
                {
                    config.SetApplicationName(Constants.AppName);
                    config.AddCommand<PulumiPreviewCommand>("preview");
                    config.AddCommand<PulumiUpCommand>("up");
                });
                return app;
            });
    });

public sealed class PulumiService : BackgroundService
{
    public PulumiService(ICommandApp appCommand, IHostApplicationLifetime appLifetime, ILogger<PulumiService> logger)
    {
        AppCommand = appCommand;
        AppLifetime = appLifetime;
        Logger = logger;
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        await AppCommand.RunAsync(Environment.GetCommandLineArgs()[1..]);
        AppLifetime.StopApplication();
    }

    private ICommandApp AppCommand { get; }
    private IHostApplicationLifetime AppLifetime { get; }
    private ILogger Logger { get; }
}

The missing piece is being able to easily integrate with the generic host dependency injection, such that I can wire up the commands in ConfigureServices too.

Thoughts? (Besides thinking I am crazy 😁)

[thoemmi]

@gitfool That's not crazy, I'm using the generic host with Spectre CLI too. In fact, it's already possible. The example Injection shows how to use IServiceCollection: implement your own ITypeRegistrar and ITypeResolver, and Spectre will register your commands in the IServiceCollection automatically.

In my application I have changed the implementation of ITypeRegistrar and ITypeResolver for better support of the generic host:

public sealed class TypeRegistrar : ITypeRegistrar
{
   private readonly IHostBuilder _builder;

   public TypeRegistrar(IHostBuilder builder)
   {
      _builder = builder;
   }

   public ITypeResolver Build()
   {
      return new TypeResolver(_builder.Build());
   }

   public void Register(Type service, Type implementation)
   {
      _builder.ConfigureServices((_, services) => services.AddSingleton(service, implementation));
   }

   public void RegisterInstance(Type service, object implementation)
   {
      _builder.ConfigureServices((_, services) => services.AddSingleton(service, implementation));
   }

   public void RegisterLazy(Type service, Func<object> func)
   {
      if (func is null) throw new ArgumentNullException(nameof(func));

      _builder.ConfigureServices((_, services) => services.AddSingleton(service, _ => func()));
   }
}

public sealed class TypeResolver : ITypeResolver, IDisposable
{
   private readonly IHost _host;

   public TypeResolver(IHost provider)
   {
      _host = provider ?? throw new ArgumentNullException(nameof(provider));
   }

   public object? Resolve(Type? type)
   {
      return type != null ? _host.Services.GetService(type) : null;
   }

   public void Dispose()
   {
      _host.Dispose();
   }
}

My Program class looks like this:

public class Program
{
   public static int Main(string[] args)
   {
      var host = CreateHostBuilder(args);

      var registrar = new TypeRegistrar(host);

      var app = new CommandApp<MyDefaultCommand>(registrar);
      app.Configure(c => c.AddCommand<AnotherCommand>("other"));
      app.Configure(c => c.AddCommand<ThirdCommand>("third"));
      return app.Run(args);
   }

   public static IHostBuilder CreateHostBuilder(string[] args) =>
      Host
         .CreateDefaultBuilder(args)
         .ConfigureServices((hostContext, services) =>
         {
            // add service registrations here
            services.AddSingleton<ISomeService, SomeService>();
         });
}

[gitfool]

The key is to use the IHostBuilder with the TypeRegistrar since it delays building the host and DI container until after CommandApp has registered its services.

[gitfool]

Makes sense now that I have it working but it does feel slightly wonky - it would be nicer if CommandApp could split registering services with the DI container from subsequently running.

[stephen776]

Is there anyway to access CommandSetting inside ConfigureServices?

I wasn’t to pass a DB password as a command setting and use it when setting up my DbContext and registering it in the container.

[MrHinsh]

Id like to have the same question as @stephen776.

I have some configuration options for the services that require access to the command settings.

[phil-scott-78]

In addition to what @thoemmi posted, I have a slightly different method over here that worked well for me - https://github.com/phil-scott-78/spectre-aspnet/blob/main/AspNetCoreApp/Infrastructure/SpectreHostingExtensions.cs

I'm going a bit of a roundabout way of doing it because my tool is being used to debug and inspect the host, so I didn't want to add any of the console tooling into the host's container.

Given enough time, I think we might add an official package to integrate easily so it's great seeing how others are approaching this problem and for what needs.

[gitfool]

AFAICT, this never builds the host, so it bypasses the other benefits of using generic host.

[jouniheikniemi]

Given enough time, I think we might add an official package to integrate easily so it's great seeing how others are approaching this problem and for what needs.

What are you thinking about the passing of time these days, ten months after the original comment? I would love to see the OOTB integration to the .NET default DI stack happen, as pasting those two files around gets pretty old after a couple of apps. This is particularly true for a library that brands itself on unit testability - there's currently an incentive for static dependency resolution.

[patriksvensson]

I don't think we will see an OOTB integration with the .NET DI stack since we don't want to add any external dependencies in Spectre.Console for specific technologies. We might add a separate package at some point for this, but it's really not a priority since time is short as it is.

Here is a sample demonstrating how to integrate with .NET DI and the console host: https://github.com/patriksvensson/spectre.console-di-sample

[jouniheikniemi]

That's fair, and by OOTB I actually meant a separate "first-party" package, but one that is easy to discover and use. I realize time is short, but perhaps the real question is more along the lines of "Would you take a PR if somebody worked on one?"

[WurliMonkhaven]

To add something I've been looking for after leaving Cysharp's ConsoleAppFramework; you can do a fun trick here to create a kind of "session" mode for your console app!

In your TypeRegistrar.cs, add a local variable like this:

private TypeResolver _cachedTypeResolver;

then in the Build() method of the registrar, something like:

//Bonus points for wrapping this in a nice spinner for a e s t h e t i c
if(_cachedTypeResolver == null) _cachedTypeResolver = new TypeResolver(_builder.Build());
return _cachedTypeResolver;

Finally, over in the TypeResolver.cs, in the Dispose() method:

public void Dispose()
{
    // Commented out to prevent Spectre from disposing the host after running!
    // _host.Dispose()
}

Now you can set up a loop however you like to take arguments in, and call app.Run(yourInputArgs) as many times as you like. The same host and dependencies get reused until you kill the app. Maybe write a fancy prompt and some jazz for it, and you've got a session-style shell to your command app. The dependencies are built once for the first command, then get reused after that (which also means you can take advantage of EF caching!).

This was massively helpful for me in building a personal devtool. I wanted to have a command app that could do DbContext stuff and use some very heavyweight/slow-loading assemblies and systems. Without this, you have to reload the entire host and the dependencies for every command you want to run. And waiting 20-30 seconds for tiny queries and commands wasn't happening.

Now I can just leave my little app running in the background and run commands whenever I need 'em :)

Massive love and rep @thoemmi for your writeup on generic host integration!