Update on Wolverine 3.0 and Aspire

I had earlier said that “full” support for .NET Aspire would be a key part of the Wolverine 3.0 plans. After kicking the tires more on .NET Aspire and seeing where user priorities and our own road map is, I’m going to back off that statement quite a bit. Here’s what’s definitely in and actually ready to go for 3.0 as it pertains to Wolverine + Aspire:

• Wolverine was decoupled from Lamar such that it can run with the built in ServiceProvider. We’ll add an add in adapter to still use Lamar as well so folks don’t have to switch out IoC tools for the new Wolverine (Lamar is much more forgiving and supports a lot of use cases that ServiceProvider does not, so you may not want to switch)
• That last point was important because the changes to the internals also made it possible for Wolverine to be able to use any flavor of application bootstrapping like Host.CreateApplicationBuilder() whereas before Wolverine was limited to IHostBuilder (there were internal reasons for that). Some of the .NET Aspire client libraries depend on different versions of the application builders, so Wolverine needed to adapt. And folks wanted that anyway, so there we go.

Now, as to what else Wolverine will support, it’s perfectly possible to use Aspire to launch Wolverine systems and Wolverine (and Marten) can happily export their Open Telemetry tracing and metrics to the .NET Aspire dashboard at runtime. You can see an example of that in my earlier post Marten, Metrics, and Open Telemetry Support.

Now on to the trickier parts. One of the things that .NET Aspire does is act as a replacement for docker compose for infrastructural concerns like SQL Server, PostgreSQL, Rabbit MQ, or Kafka and acts as a global configuration element for other infrastructure things like Azure Service Bus or AWS SQS. Somebody might have to correct me, but more or less, Aspire is launching the various applications and poking through environment variables for the configuration data that Aspire itself is defining and controlling (like PostgreSQL connection strings for example). To make that information easier to consume, the Aspire team and community have built a bunch of client adapter libraries like Aspire.RabbitMQ.Client or Aspire.Npgsql that are meant to hook your application to the resources configured by Aspire by adding service registrations to the application’s underlying IoC container.

After some research earlier this week as I get to work toward the Wolverine 3.0 release, I think that:

• Aspire.Npgsql can already be used as is with Marten at least, and with the Wolverine + Marten integration. A little more work could enable Aspire.Npgsql to be used with PostgreSQL storage within Wolverine for use by itself or with EF Core. There’s no need for us to take a direct dependency on this library though
• Aspire.RabbitMQ.Client creates a version conflict with the RabbitMQ.Client library for us right now, so that’s out. I’m leery of taking on the potential diamond dependency issue anyway, so we’ll probably never take a dependency on it
• Aspire.Microsoft.Data.SqlClient registers a scoped dependency for SqlConnection, but doesn’t expose the connection information any other way. This would require quite a few changes to the Wolverine internals that I don’t think would pay off. We won’t use this, again partially because of the fear of diamond dependencies
• Aspire.Azure.Messaging.ServiceBus just isn’t usable. It precludes several options for authentication to Azure Service Bus, and using it would knock out Wolverine’s ability to set up or tear down resources on the fly — which I think is a competitive advantage of Wolverine over other alternatives, so I’m not enthusiastic about this one either
• Aspire.Confluent.Kafka doesn’t fit Wolverine at all where we want to have the broker connection information upfront, and where Wolverine is completely responsible for setting up consumers and producers

All told though, I don’t think that any of the Aspire.* client libraries are usable out of the box. I guess I’m not sure if these libraries were even meant to be used or are just example code that folks like me should use to build in more specific support. In all cases, I’m voting to hold off for now on any new, direct Aspire support until someone — hopefully a contributor or JasperFx Software client — directly asks for it.