Wolverine & Aspire

[jeremydmiller]

I'm (Jeremy) interested in seeing what Project Aspire could do in conjunction with Wolverine.

My notes so far on what the integration would require:

First Sample

Stick with Rabbit MQ and Marten/PostgreSQL. At least two projects, a web api project and a headless service sending messages back and forth. Focus on the OpenTelemetry tracking for now. Research what if anything this could do for integration testing

Rabbit MQ

Aspire registers a Rabbit MQ IConnection in the container. We can check to see if that exists in the container if there is nothing explicitly configured in the Wolverine configuration for connection.

From a little bit of research, Aspire registers the IConnectionFactory service as a singleton. The RabbitMqTransport should look for that if no explicit IConnectionFactory or connection string is registered w/ the transport. Easy money

Azure Service Bus

Aspire registers a ServiceBusClient service. That's most of what we need. Might need more for admin

PostgreSQL

Aspire registers an NpgsqlDataSource. This one's a little trickier, because we don't assume a single postgresql database. And also, registering postgresql is pretty simple. Could still have a recipe where Marten wraps its own connection factory around a data source. Could also move Marten 7 & Weasel to using the data source model. We've already thought about that anyway.

Not sure Aspire helps much for multi-tenancy, or cases where you use separate data stores at all

EF Core w/ PostgreSQL or SQL Server

This one's a little problematic. Wolverine has its own extensions for configuring DbContext. We'd need to get smarter about the DbContext configuration. Can you apply external extensions to the DbContext registration and configuration? More research here.

Need the DbContextOptions to be a singleton if at all possible. This won't play well with multi-tenancy either.

[Xzelsius]

I am not sure on what you mean with your comment in the EF Core part.
But in a personal project I am able to add a new extension to just about any DB context using the DbContextOptionsBuilder.

This is the code that registers a new extension

protected virtual TBuilder WithOption(Func<TExtension, TExtension> setAction)
{
    var extension = OptionsBuilder.Options.FindExtension<TExtension>() ?? new TExtension();

    extension = setAction(extension);

    ((IDbContextOptionsBuilderInfrastructure) OptionsBuilder).AddOrUpdateExtension(extension);

    return (TBuilder) this;
}

whereas TExtension is IDbContextOptionsExtension.

But maybe I got you wrong.
Anyway, happy to help you out on that EF Core stuff if I can :)

[jeremydmiller]

Gotcha. The problem is that the extensions in this case will need to be coming from a DI container and completely from outside the core DbContext code file.

[Xzelsius]

Never tried that DI part, but I think this could still work somehow.
But I would need to look into how Wolverine works with EF Core.

In my personal project I do register additional extensions within the .AddDbContext<> call. So it is not within the DbContext class itself.

[jeremydmiller]

Yeah, but the registration would need to happen outside of your original call to AddDbContext(). And Aspire wants to own the AddDbContext() mechanism

[Hawxy]

Not sure Aspire helps much for multi-tenancy, or cases where you use separate data stores at all

Looks like this will be solved at the NpgsqlDataSource level at some point: npgsql/npgsql#4523