Request: Add .AddWolverine() overload with IServiceProvider access

[penenkel]

Is your feature request related to a problem? Please describe.
I would like to be able to late-bind configuration values. For that the usual pattern is to access IConfiguration via the IServiceProvider while configuring the options in a .Add<Service>(provider => <Service>Options) extension.

Describe the solution you'd like
Add AddWolverine(this IServiceCollection services, Func<IServiceProvider, WolverineOptions> optionSource) overload analogue to - for example - the AddMarten(this IServiceCollection services, Func<IServiceProvider, StoreOptions> optionSource ) overlaod.

Additional context
I also noticed that all documentation and samples use builder.Host.UseWolverine() instead of builder.Services.AddWolverine(). Is that intentional? As far as I know builder.Host is just a shim in the AspNetCore framework to provide backwards compatibility for libraries that only offer the old-style integration. As you already provide an .AddWolverine extension, I would have expected that to be the primary and preferred way to setup.

[jeremydmiller]

Marten's bootstrapping is much simpler. And my muscle memory is all from the early days when Wolverine only supported IHostBuilder, that's all.

I'm deeply unenthusiastic. Why would you need that? You can use the IConfiguration at bootstrapping time anyway. You can also inject IWolverineExtension at will for weird DI reliant configuration. I'd take syntactic sugar helpers to make that quicker w/ an inline lambda I suppose.

@penenkel But if you really care: Feel very free to contact us at sales@jasperfx.net about that one.

I'm converting this to a discussion

[penenkel]

I will look into IWolverineExtension, I have not investigated that yet.

I ran into this trying to cobble together a testing harness. I haven't worked with AspNetCore for a while, so I naively assumed the following would work wrt. providing the expected configuration values. But this does not work for any configuration that is accessed before var app = builder.Build(); is called. Which makes sense if one knows/remembers that the newish single file bootstrap is just a thin layer over the older multi-step startup class mechanism, but it is easy to overlook and only relevant in edge-cases like testing setups or interdependent framework configuration.

public class AppFixture : IAsyncLifetime
{
    private readonly PostgreSqlContainer _postgres = new PostgreSqlBuilder("postgres:17-alpine")
        .WithDatabase("app")
        .WithUsername("postgres")
        .WithPassword("postgres")
        .Build();

    public IAlbaHost Host { get; private set; } = default!;
    public CommandCapturingLogger CommandLogger { get; } = new();

    public async ValueTask InitializeAsync()
    {
        await _postgres.StartAsync();



        Host = await AlbaHost.For<Program>(b =>
        {
            b.ConfigureAppConfiguration(
                (_, cfg) =>
                    cfg.AddInMemoryCollection(
                        new Dictionary<string, string?>
                        {
                            {"ConnectionStrings:app", _postgres.GetConnectionString()},
                        }
                    )
            );

            b.ConfigureServices((_, services) =>
            {
                services.AddSingleton<IMartenSessionLogger>(CommandLogger);
                services.DisableAllExternalWolverineTransports();
                services.RunWolverineInSoloMode();
            });
        });
    }

    public async ValueTask DisposeAsync()
    {
        if (Host != null)
        {
            await Host.DisposeAsync();
        }

        await _postgres.DisposeAsync();
    }
}

[penenkel]

I just figured out that Alba already has an mechanism that can be used override the configuration in a manner that solves this particular problem: IAlbaExtension s apply their configuration overrides through the IHostBuilder.ConfigureHostConfiguration method, which targets the host configuration which the configuration portion that is available during bootstrap pre builder.Build. Not quite the same as late binding the actual application configuration, but good enough for test code I guess.

public class AppFixture : IAsyncLifetime
{
    private readonly PostgreSqlContainer _postgres = new PostgreSqlBuilder("postgres:17-alpine")
        .WithDatabase("app")
        .WithUsername("postgres")
        .WithPassword("postgres")
        .Build();

    public IAlbaHost Host { get; private set; } = default!;
    public CommandCapturingLogger CommandLogger { get; } = new();

    public async ValueTask InitializeAsync()
    {
        await _postgres.StartAsync();

        Host = await AlbaHost.For<Program>(
            b =>
            {
                b.ConfigureServices(
                    (_, services) =>
                    {
                        services.AddSingleton<IMartenSessionLogger>(CommandLogger);
                        services.DisableAllExternalWolverineTransports();
                        services.RunWolverineInSoloMode();
                    }
                );
            },
            new AlbaConfigExtension(
                new Dictionary<string, string?>
                {
                    { "ConnectionStrings:app", _postgres.GetConnectionString() },
                    { "services:watch:http:0", "https://localhost/_wolverine/invoke" }
                }
            )
        );
    }

    public async ValueTask DisposeAsync()
    {
        if (Host != null)
        {
            await Host.DisposeAsync();
        }

        await _postgres.DisposeAsync();
    }
}

class AlbaConfigExtension : IAlbaExtension
{
    public AlbaConfigExtension(IEnumerable<KeyValuePair<string, string?>> config)
    {
        _config = [.. config];
    }

    private readonly List<KeyValuePair<string, string?>> _config;

    void IAlbaExtension.Configure(IAlbaHostBuilder builder)
    {
        builder.ConfigureConfiguration(b =>
        {
            b.AddInMemoryCollection(_config);
        });
    }

    Task IAlbaExtension.Start(IAlbaHost host) => Task.CompletedTask;

    void IDisposable.Dispose() { }

    ValueTask IAsyncDisposable.DisposeAsync() => ValueTask.CompletedTask;
}