Configuration Extensions

Wolverine supports the concept of extensions for modularizing Wolverine configuration with implementations of the IWolverineExtension interface:

/// <summary>
///     Use to create loadable extensions to Wolverine applications
/// </summary>
public interface IWolverineExtension
{
    /// <summary>
    ///     Make any alterations to the WolverineOptions for the application
    /// </summary>
    /// <param name="options"></param>
    void Configure(WolverineOptions options);
}

^{snippet source | anchor}

Here's a sample:

public class SampleExtension : IWolverineExtension
{
    public void Configure(WolverineOptions options)
    {
        // Add service registrations
        options.Services.AddTransient<IFoo, Foo>();

        // Alter settings within the application
        options
            .UseNewtonsoftForSerialization(settings => settings.TypeNameHandling = TypeNameHandling.None);
    }
}

^{snippet source | anchor}

Extensions can be applied programmatically against the WolverineOptions like this:

using var host = await Host.CreateDefaultBuilder()
    .UseWolverine(opts =>
    {
        // Including a single extension
        opts.Include<SampleExtension>();
    }).StartAsync();

^{snippet source | anchor}

Lastly, you can also add IWolverineExtension types to your IoC container registration that will be applied to WolverineOptions just before bootstrapping Wolverine at runtime. This was originally added to allow for test automation scenarios where you might want to override part of the Wolverine setup during tests. As an example, consider this common usage for disabling external transports during testing:

// This is using Alba to bootstrap a Wolverine application
// for integration tests, but it's using WebApplicationFactory
// to do the actual bootstrapping
await using var host = await AlbaHost.For<Program>(x =>
{
    // I'm overriding 
    x.ConfigureServices(services => services.DisableAllExternalWolverineTransports());
});

^{snippet source | anchor}

Behind the scenes, Wolverine has a small extension like this:

internal class DisableExternalTransports : IWolverineExtension
{
    public void Configure(WolverineOptions options)
    {
        options.ExternalTransportsAreStubbed = true;
    }
}

^{snippet source | anchor}

And that extension is just added to the application's IoC container at test bootstrapping time like this:

public static IServiceCollection DisableAllExternalWolverineTransports(this IServiceCollection services)
{
    services.AddSingleton<IWolverineExtension, DisableExternalTransports>();
    return services;
}

^{snippet source | anchor}

In usage, the IWolverineExtension objects added to the IoC container are applied after the inner configuration inside your application's UseWolverine() set up.

Wolverine Plugin Modules

TIP

Use this sparingly, but it might be advantageous for adding extra instrumentation or extra middleware

If you want to create a Wolverine extension assembly that automatically loads itself into an application just by being referenced by the project, you can use a combination of IWolverineExtension and the [WolverineModule] assembly attribute.

Assuming that you have an implementation of IWolverineExtension named Module1Extension, you can mark your module library with this attribute to automatically add that extension to Wolverine:

[assembly: WolverineModule(typeof(Module1Extension))]

^{snippet source | anchor}

Configuration Extensions #

Wolverine Plugin Modules #

Configuration Extensions

Wolverine Plugin Modules