Wolverine is taking a leap forward with the first 3.0 Alpha Release

Why should you care about this Wolverine tool anyway? I’d say that if you’re building just about any kind of server side .NET application, that Wolverine will do more than any other existing server side .NET framework in the mediator, background processing, HTTP, or asynchronous messaging space to simplify your code, maximize the testability of your system code, and do so while still helping you write robust, well performing systems.

The first Wolverine 3.0-alpha-1 release just landed on Nuget for anybody who is either waiting on 3.0 features or willing to try out the new bits. Just to rewind, here was the theoretic plans for Wolverine 3.0, with the Aspire integration having fallen off a bit.

See the Wolverine migration guide for more details.

There are some additive changes to address some previous limitations of the Wolverine tooling I’ll get to below, but the two big ticket items in 3.0 are:

• Wolverine is now completely decoupled from Lamar and happily able to run with the built in ServiceProvider now. Before, Wolverine was quietly replacing your IoC container with Lamar because it heavily relied on Lamar internal behavior for its runtime code generation. 3.0 ended that particular limitation. Not everyone cared, but the folks who did care, were particularly loud about their unhappiness about that and Lamar is probably heading into the subset anyway in the future. I felt like this was a very important limitation of Wolverine to address in this release. It’s also a precursor to further usage of .NET Aspire and enabling Wolverine to play nicely with just about any common recipe for bootstrapping .NET applications (Blazor, WPF, Orleans, you name it).
• The leader election subsystem in Wolverine was pretty close to 100% rewritten to a much simpler, and so far as the internal testing shows, far more reliable and performant mechanism. This subsystem has been way too problematic in real usage, and I’m beyond relieved that there’s some serious improvements coming for this

As for smaller things so far, some other highlights are:

• Being able to utilize multiple handlers for the same message type in the same application, and even determine which handlers execute for particular external listeners
• The stateful saga support in Wolverine got some necessary optimistic concurrency protection at the behest of a JasperFx Software client
• New “lightweight” saga options to utilize either PostgreSQL or Sql Server as JSON storage mechanisms so you don’t have to suffer the pain of EF Core mapping just to persist sagas if you aren’t using Marten
• The Rabbit MQ integration is using the new version of the Rabbit MQ client that is finally async all the way through to prevent deadlock issues. There is also some significant improvement to the Rabbit MQ transport for header exchanges and more control over messaging conventions
• There is a new Nuget of compliance tests for Wolverine to hopefully speed up the construction of new saga persistence providers, messaging transports, or message storage options that I hope will unlock new functionality in the following months

I’m actually hopeful that the final 3.0 release goes out early next week. I’m not sure what the remaining work will be to make it in, but I’m wanting to tackle:

• Message batching, because that comes up fairly often
• A round of enhancements to the EF Core integration with Wolverine to try to increase Wolverine utilization for folks who don’t use Marten for some bizarre reason