How can I prevent EF "The context cannot be used while the model is being created" errors?

Question

Looking at my Elmah error logs, I am seeing a few InvalidOperationExceptions from Entity Framework that deal with:

The context cannot be used while the model is being created.

This is with the latest EF CodeFirst library from Nuget. The only information I have been able to find on the net is that it is being caused by having data contexts as singletons, which is most certainly not my case. In my Windsor installer, my EF unit of work structure is being registered with:

container.Register(Component.For<IUnitOfWork>()
                            .ImplementedBy<EFUnitOfWork>()
                            .LifeStyle
                            .PerWebRequest);

I am able to recreate the error by hitting F5 in VS to start a debugging sessions, and while IIS is spinning up load up a second webpage to the debug session.

I suspect it is because the user is trying to access the system while Asp.net has unloaded due to the lack of activity, which makes sense as my product is currently in a very very small beta test. However, since real people are using the website with live data, I need as little errors occurring as possible.

Does anyone have any idea how to prevent this from occurring?

---

Edit: I updated my windsor controller to now contain the following code:

        container.Register(Component.For<IUnitOfWork>().ImplementedBy<EFUnitOfWork>().LifeStyle.PerWebRequest);
        using (var context = new MyJobLeadsDbContext())
        {
            context.Set<UnitTestEntity>().Any();
        }

However, when I attempt to perform a 2nd web request while IIS is loading the application, the previous error still occurs

---

Edit 2: As requested, here is the stack

   at System.Data.Entity.Internal.LazyInternalContext.InitializeContext()
   at System.Data.Entity.Internal.InternalContext.Initialize()
   at System.Data.Entity.Internal.InternalContext.GetEntitySetAndBaseTypeForType(Type entityType)
   at System.Data.Entity.Internal.Linq.InternalSet`1.Initialize()
   at System.Data.Entity.Internal.Linq.InternalSet`1.get_InternalContext()
   at System.Data.Entity.Infrastructure.DbQuery`1.System.Linq.IQueryable.get_Provider()
   at System.Linq.Queryable.Where[TSource](IQueryable`1 source, Expression`1 predicate)
   at MyApp.DomainModel.Queries.Users.UserByEmailQuery.Execute() in C:\Users\KallDrexx\Documents\Projects\MyApp\MyApp.DomainModel\Queries\Users\UserByEmailQuery.cs:line 44
   at MyApp.Infrastructure.MyAppMembershipProvider.GetUser(String email, Boolean userIsOnline) in C:\Users\KallDrexx\Documents\Projects\MyApp\MyApp\Infrastructure\MyAppMembershipProvider.cs:line 102
   at System.Web.Security.Membership.GetUser(String username, Boolean userIsOnline)
   at System.Web.Security.Membership.GetUser()
   at MyApp.MyAppBaseController.Initialize(RequestContext requestContext) in C:\Users\KallDrexx\Documents\Projects\MyApp\MyApp\MyAppBaseController.cs:line 23
   at System.Web.Mvc.ControllerBase.Execute(RequestContext requestContext)
   at System.Web.Mvc.ControllerBase.System.Web.Mvc.IController.Execute(RequestContext requestContext)
   at System.Web.Mvc.MvcHandler.<>c__DisplayClass6.<>c__DisplayClassb.<BeginProcessRequest>b__5()
   at System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass1.<MakeVoidDelegate>b__0()
   at System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass8`1.<BeginSynchronous>b__7(IAsyncResult _)
   at System.Web.Mvc.Async.AsyncResultWrapper.WrappedAsyncResult`1.End()
   at System.Web.Mvc.MvcHandler.<>c__DisplayClasse.<EndProcessRequest>b__d()
   at System.Web.Mvc.SecurityUtil.<GetCallInAppTrustThunk>b__0(Action f)
   at System.Web.Mvc.SecurityUtil.ProcessInApplicationTrust(Action action)
   at System.Web.Mvc.MvcHandler.EndProcessRequest(IAsyncResult asyncResult)
   at System.Web.Mvc.MvcHandler.System.Web.IHttpAsyncHandler.EndProcessRequest(IAsyncResult result)
   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Solution 1

I finally figured out the true cause of this, at least for me.

The issue was that I was retrieving a DbContext from Windsor in my custom Asp.Net Membership provider. This caused an issue because the membership provider has a lifespan of the whole application, while all other retrieval calls for the db context were new db contexts for the specific web requests. This meant that two database contexts were "spinning up" at the same time and thus this error was thrown.

This also caused a lot of hard to debug entity caching issues as well, so anyone who uses EF in their membership provider needs to be real careful about their context lifetime.

---

Edit

For example:

public class CustomMembershipProvider : MembershipProvider
{
    private IServiceFactory _serviceFactory;

    public CustomMembershipProvider() : this(null) { }

    public CustomMembershipProvider(IServiceFactory factory)
    {
        // IF no factory was provided, we need to get one from the bootstrapper
        if (factory == null)
            _serviceFactory = new WindsorServiceFactory(Bootstrapper.WindsorContainer);
        else
            _serviceFactory = factory;
    }

    public override string ResetPassword(string email, string answer)
    {
        var unitOfWork = GetUnitOfWork();
        return new ResetUserPasswordCommand(unitOfWork).WithUserEmail(email).Execute();
    }

    private IUnitOfWork GetUnitOfWork()
    {
       return _serviceFactory.GetService<IUnitOfWork>();
    }
}

The idea being that any action the membership provider performs gets the UnitOfWork class from Windsor, and uses that to perform the action (in this case my UnitOfWork class is a repository holder to wrap up my EF data context)

Solution 2

I ran into the same issue in a multithreaded WPF app.

My workaround was to force DbContext initialization from the Windsor installer:

container.Register(Component.For(TheDbContext.Blah.Blah));
using (var context = new TheDbContext())
      context.Set<SomeRandomEntity>().Any();

I might add in my opinion this qualifies as a bug in EF: they should have used thread-safe (with locks, or whatever) code for DbContext initialization.

Of course, a better solution is what NHibernate does: the SessionFactory is an explicitly created, separate object from the Session.

Solution 3

When i encountered this issue, i found it was a dbconnection gone wrong.

I corrected my EntityFramework dbconnection string and all was fine

Comments

[KallDrexx]

Calling container.Resolve<IUnitOfWork>() and making a DB call does not stop this issue from happening unfortunately. I agree with you that EF should be thread-safe for initialization, and it's really annoying that it's not.

[Diego Mijelshon]

@KallDrexx: it does if the container initialization itself is done in a thread-safe way. I'm not even using resolve; that code is part of my DbInstaller (a class implementing IWindsorInstaller)

[KallDrexx]

Ok I tried not using my unit of work and interacting with the DbContext itself. Now my 2nd request dies with The underlying provider failed on Open. on the same line of code, so this still doesn't seem to work for me :(

[Diego Mijelshon]

@KallDrexx: post the full exception with stack trace.

[KallDrexx]

Well I can't get that error to happen again, but the original error now occurs each time. I posted my new windsor installer code in the main question

[KallDrexx]

I have posted the full stack trace of the he context cannot be used while the model is being created. exception

[Diego Mijelshon]

@KallDrexx: where/when are you initializing the container?

[KallDrexx]

First of all, thanks for still coming back to this :). After looking for the answer to this I think I may have an idea of why this is happening. My Windsor container is being initialized in a class that is marked with [assembly: WebActivator.PostApplicationStartMethod (typeof(Bootstrapper), "Wire")], thus it's not initializing the container until after the app starts. I am wondering if I change this to PreApplicationStartMethod if that will make this issue go away. I'll give it a try when I get home!

[Diego Mijelshon]

@KallDrexx: trying can't hurt... I'm pretty sure about why the exception occurs, it's just a matter of finding out how to force initialization to be complete before the context is accessed again.

[KallDrexx]

Well that's why I'm thinking PreApplicationStartMethod should work, because that should cause the installer to run (with your suggested addition of calling the DbContext) prior to the application fully starting, and thus the 2nd web request may not execute until after the context is fully up and running (therefore not causing this exception to occur)

[Diego Mijelshon]

@KallDrexx: You should log debug information to confirm if the second request is being executed before initialization is complete.

[KallDrexx]

Sorry I should have included that. I solved it by making EVERY one of my membership provider methods make a new request to Windsor for my DbContext, and never used the same DBContext outside that method. Prior to that I was requesting the DbContext via my membership provider's constructor and was storing it for later keeping, which caused the issue.

[Suren]

I just forced container to init itself like Diego and everything was right, the different is I used a fake query : dbcontext.Set<User>().Select(q => q.Id)

[RBT]

Sorry to bother you guys. It was failing because of wrong attribute on one of the properties of my POCO classes [Column("ToDoItem", TypeName = "NVARCHAR(2000)")] works. Length of varchar and nvarchar data types are required to be mentioned explicitly through stringLength attribute. It can't be mentioned in-line inside Column attribute as long as it is not MAX length.