Resolving Application Services From NpgsqlMigrationsSqlGenerator

[TimFeldmann-Work]

With .NET 9.0, the ApplicationServiceProvider property present on the INpgsqlSingletonOptions interface used when implementing a custom NpgsqlMigrationsSqlGenerator was removed.

I understand this was always intended to be an internal API, however it was the only reasonable way I could resolve the IHostEnvironment from my application's service provider in order to change the SQL that was run depending on which environment my services are deployed in.

What is the recommended way of accessing the application's service provider from custom internal EF infrastructure? I understand we can use .UseInternalServiceProvider during startup, however this opens up a massive can of worms with the inability to use helper methods such as .AddInterceptor among others.

My last resort is using some static class to cache the IHostEnvironment and using it from my NpgsqlMigrationsSqlGenerator however I would like to avoid this hack if possible.

Thank you!

[TimFeldmann-Work]

For anyone running into something similar in the future:

I ended up creating a custom IDbContextOptionsExtension class which accepts my application's IServiceCollection as a constructor parameter.

Inside of ApplyServices(), I resolve the singleton services I want from my application's service collection and add the types and concrete implementation instances to EF's internal IServiceCollection.

At this point, the application services I want available inside of EF's internal service provider are now available to EF infrastructure services.

I would be careful taking this approach when resolving non-singleton services from inside ApplyServices() using a built application IServiceProvider. Instead, simply register a Scoped / Transient type directly to EF's IServiceCollection without a concrete instance implementation.