Pattern for seeding database with EF7 in ASP.NET 5

[ducalai]

Hi

I am playing around with MVC Music Store and I try to access Entities from DbContext once it has been initialized with very last line SampleData.InitializeMusicStoreDatabaseAsync(app.ApplicationServices).Wait() in Startup.cs file.

If right after that static call, I reach DbContext using var db = app.ApplicationServices.GetService(), then every access to db.[Entity].ToListAsync() generates an "Object reference not set to an instance of an object" exception.

This exception is not thrown if I remove the using block when accessing the DbContext in SampleData.InitializeMusicStoreDatabaseAsync.

This exception was not thrown in beta6. I am currently running beta7 version. Is that a bug or am I doing anything wrong?

Thanks for your help
Alain

[rowanmiller]

Can you provide sample code that we can use to reproduce the issue you are seeing?

[divega]

If I understand what @ducalai says correctly, his code might be trying to use a DbContext instance from the same DI scope that has already been disposed by the using statement in SampleData.InitializeMusicStoreDatabaseAsync(). This is expected not to work, but the NullRefException is not expected.

[ducalai]

Yes you are right. I do understand that in the same DI scope, if context has been disposed by the using statement, this is not expected to work.

If you want a simple sample code, just add those two following lines of code in MVC Music Store sample project, after the very last line of Configure(IApplicationBuilder app) method of MusicStore.xproj:

//Get context
var context = app.ApplicationServices.GetRequiredService();
var albums = context.Albums.ToListAsync();//This line throws NullRefException

So what is the correct way to access DbContext content in that current scope? Is the using statement incorrect and I should rely on DI to dispose DbContext at the end of scope? Will this scope last untill next application restart?

[divega]

Yes, applying a using statement on a context whose lifetime is controlled by DI is not the best idea because the context instance is supposed to be shared by any code running in the same request. Of course, in tge unmodified version of MusicStore this wasn't causing any problems because nothing else was trying to use the context.

I believe the code in Startup.Configure() gets executed in a request scope so the context wouldn't be kept alive for the whole application lifetime, but I am not 100% sure (@HaoK do you know from the top of your head?).

For what it is worth the pattern that creates the database on start up used in MusicStore isn't something we would recommend for production deployment in real world applications.
I believe from the top

[HaoK]

Configure actually is run when building the application pipeline, so there is no request at this point. The request scope gets added automatically to the pipeline via the IStartupFilter around the pipeline that is build by Configure, but this SampleData.Initialize call is being run as a sideeffect of building the pipline using the ApplicationServices that's being passed in from the IAppBuilder.

[divega]

Thanks for the details. Hence I assume the DbContext obtained here from DI will be kept alive for the duration of the application, right?

[ducalai]

Seems that this SampleData.Initialize call in Configure method is not the optimal way to initialize database. Do you have a more recommended solution?

[divega]

@rowanmiller has put together a sample of a seeding method and its usage.

Notice the sample does the seeding in Startup.Configure() so it has the same issues we have discussed in this thread. We will look at this problem and come back to you when we have a solution.

[divega]

@rowanmiller and I discussed this briefly and we think there isn't yet a great place to do this kind of work in an ASP.NET 5.0 application. But we are going to try to work around it by obtaining the DbContext from a scoped service provider (similar to what is exposed later to each Web request) so that DbContext instance used for seeding shouldn't stay in memory after the service scope is disposed. E.g. the code in his sample would change to look somewhat like this:

using(var serviceScope = app.ApplicationServices
              .GetRequiredService<IServiceScopeFactory>()
              .CreateScope())
{
    var context = serviceScope.ServiceProvider.GetService<UnicornStoreContext>();
...

[ducalai]

Sounds great! Thanks for your work. I will wait for your news

[HaoK]

Feels like we are missing an OnApplicationStart feature that takes care of this, (creates a scope, calls the delegate) Altho the scope might just be an EF thing

[rowanmiller]

👍

[divega]

@HaoK Assuming I have understood everything correctly it seems that any service that is registered as scoped will be created with the wrong lifetime if used in Startup.Configure(). Maybe the EF seeding scenario helps make that more evident but I don't think it is just an EF issue.

Can you help by articulating this in a bug and gauge the chances of us fixing it? (the fix may be adding a separate method like the OnApplicationStart() you mentioned, but I think it would be good to discuss if we need to do anything about consuming scoped services from Startup.Configure() or if this is something that just needs to be documented).

[HaoK]

Well, the general issue is that there is no such thing as a scope in the ApplicationServices, this bug is sort of related, where it would be nice if we at least detected and threw an exception when trying to resolve a scoped service from ApplicationServices, I hit this before in identity and MVC hit this behavior as well, so its definitely an easy thing to stumble into:

aspnet/DependencyInjection#88

[YZahringer]

Hello,

Another problematic case is when you use a Timer. During the callback there have no scope. So the used instances are always the same, because you have to use the ServiceProvider of the application, so always the same context.

What would be the best way to use DI with a Timer? The Timer sould perhaps create a scope during the callback and pass it in parameter? Use IServiceScopeFactory in the callback?

[divega]

I have filed a new issue at https://github.com/aspnet/Hosting/issues/373 for first class support of application code that runs at startup. In the meanwhile, running code within a service scope in Startup.Configure() seems to be the best workaround:

using(var serviceScope = app.ApplicationServices
              .GetRequiredService<IServiceScopeFactory>()
              .CreateScope())
{
    var context = serviceScope.ServiceProvider.GetService<UnicornStoreContext>();
...

This workaround is now implemented in the MusicStore sample.