New topic: Getting the DbContext outside of a Controller

[Rick-Anderson]

• Getting the DbContext outside of a Controller
• Accessing scoped services outside of an HTTP request.

per @davidfowl
There's enough confusion here that I think we should have a first class topic for it on the EF docs:

https://www.reddit.com/r/dotnet/comments/7cednh/how_to_grab_a_dbcontext_from_outside_a_controller/
We should probably also have something on accessing scoped services outside of an http request.

Can one of @ajcvickers or @divega provide the sample for Getting the DbContext outside of a Controller?

@rynowak @danroth27 who's the contact for Accessing scoped services outside of an HTTP request?

[divega]

Can one of @ajcvickers or @divega provide the sample for Getting the DbContext outside of a Controller?

@Rick-Anderson that really is a DI question, not an EF question 😸

By default AddDbContext<TContext>() registers TContext as scoped, so you want to create a DI scope first. There is already some guidance in the context of migrating from 1.x to 2.0:

https://docs.microsoft.com/en-us/aspnet/core/migration/1x-to-2x/#move-database-initialization-code

But not sure where else this could be useful besides initialization. E.g. the thread in reddit talks about a service that scheddules recurrent tasks rather tha servicing external requests. I imagine we would need general guidance on how to do that correctly.

BTW, @davidfowl pushed a change late in 2.0 which removed the need to create the DI scope if you needed to use a scoped service (e.g. a DbContext) inside Startup.Configure(), but it turns out that in 2.0 that is the last place where you want to do that anyway.

[Rick-Anderson]

@scottaddie can you review this?

[tnsturm]

We have a real use case:

We're using

<PackageReference Include="Microsoft.Azure.EventHubs" Version="2.0.0" />
<PackageReference Include="Microsoft.Azure.EventHubs.Processor" Version="2.0.1" />

in our Asp.NET Core Application.

None of the 4 entry points (public EventHubProcessor(), OpenAsync(), CloseAsync(), ProcessEventsAsync()) are integrated in the DI system, so we have to be "creative" even when only using an ILogger.

Up to Asp.NET Core 2.0, we injected an IServiceProvider into Configure() of Startup, saved that into a static property of Startup and used that in the Eventprocessor Contructor with
_logger = Startup.Current.GlobalStaticServiceProvider.GetRequiredService<ILogger<EventHubProcessor>>();

This broke with asp.NET Core 2.1 because of aspnet/Hosting#1106, now the IServiceProvider injected into Configure() is scoped and most of the time disposed at the time the EventprocessorHost is created.

Now we have to be even more creative and safe this IServiceProvider in program.cs:

IWebHost host = webhostbuilder.Build();
Startup.Current.GlobalStaticServiceProvider = host.Services;
host.Run();

and fetch the ILogger in Eventprocessor Constructor with:

_logger = Startup.Current.GlobalStaticServiceProvider.GetRequiredService<IServiceScopeFactory>().CreateScope().ServiceProvider.GetRequiredService<ILogger<EventHubProcessor>>();

None of these options are a clean solution and prone to fail in future asp.net core Versions. It would be very helpful if there would be easier ways to use the DI system in code paths which are not derived from IController or which are integrated with the DI system like Hangfire

[danroth27]

@davidfowl

[davidfowl]

None of these options are a clean solution and prone to fail in future asp.net core Versions. It would be very helpful if there would be easier ways to use the DI system in code paths which are not derived from IController or which are integrated with the DI system like Hangfire

Yes this is tricky as it hard to integrate when multiple systems want to be the owner of the container, and that's what going on here. Ideally you would register something in the DI container that activated the EventHubProcessor from the DI container. It looks like there's a factory though but I'm not 100% sure if it'll work well here.