0.6.0

ConfigureFisher(...) — the lambda form of IConfigureFisher (#70)

Four extension methods on IServiceCollection, mirroring Marten's ConfigureMarten and Polecat's ConfigurePolecat — a primary and a targeted pair, each with and without the container:

services.ConfigureFisher(options => ...);
services.ConfigureFisher((serviceProvider, options) => ...);
services.ConfigureFisher<IReportingStore>(options => ...);
services.ConfigureFisher<IReportingStore>((serviceProvider, options) => ...);

This is the surface an integration package uses to layer its own StoreOptions contributions onto a store somebody else registered. Wolverine.Fisher's ancillary-store support is the caller, and having the three stores present the same shape here is what JasperFx/wolverine#3907 asked for.

Fixed: a contribution registered against the closed IConfigureFisher<T> silently did nothing

Fisher resolves IConfigureFisher and filters by the contribution's own interfaces; Marten and Polecat resolve the closed IConfigure*<T> directly. So code ported from either — services.AddSingleton<IConfigureFisher<IMyStore>, MyConfiguration>() — registered against a service type GetServices<IConfigureFisher>() does not return, because the container matches on the service type a registration named rather than on what it implements. A contribution that compiled, registered, and never ran.

Both registration styles are now swept and deduplicated by reference, so a contribution registered against both service types is still applied once.

If you register IConfigureFisher<T> implementations this way, they will start running on 0.6.0. That is the intent — but it is a behaviour change, so it is worth checking that what they configure is what you meant.

Also

• Docs: Bootstrapping, Multiple Stores, and the migration-guide name table.

Full changelog: 1fe0468...v0.6.0