AddSqlServerDbContext forces you to use AddDbContextPool

[DKANomad]

I have been experimenting with Aspire and found a bit of an inconsistency in the docs and that API.

According to this page the DbContextPooling is a configuration option, however looking at the code I can see this isn't the case.

I'm wondering if this was a decision that was made to force context pooling, and if so I'd like to discuss changing back to it being a configuration option.

Reason being that the limitation around the access of scoped services when using context pooling. I like to leverage query filters in cases where I want to force all queries to use include a TenantId filter which requires access to a service that I can set a value in via middleware.

I wasn't sure if this would be considered an issue or if it required more conversation first.

[sandord]

I just came to the same conclusion for the same reason of needing a scoped dependency in my DbContext to support global query filtering.

I'm using Postgres though but the AddNpgsqlDbContext has the exactly same behavior: it registers the DbContext for pooling without any conditions.

It makes a lot of sense to me to make this behavior optional.

What seems to work for me as a workaround is:

// Place this after the builder.AddNpgsqlDbContext call.
builder.Services.RemoveAll<MyDbContext>();
builder.Services.AddDbContext<MyDbContext>();

Note that since we didn't remove any DbContextOptions registrations, the configuration made by AddNpgsqlDbContext still applies.

UPDATE: Don't do this, see the link below for the proper solution.

[sandord]

I just came across this thread dotnet/docs-aspire#1601 that address this issue.

Make sure you use the Postgres equivalent of EnrichSqlServerDbContext, which is called EnrichNpgsqlDbContext.