With the release of Entity Framework 6.2, it introduces the Entity Framework Code First Model Cache. Giving you the ability to load a prebuilt edmx when using code first, instead having EF generate it on startup.
This can provide a some savings on startup time.
With these changes, first AppDomain calls to context.Database.Initialize for a model with just over 600 models and a null initializer dropped from 12-14 seconds to about 1.9 seconds after the edmx was written, saving 10-12 seconds on initialization. The first call to write the edmx still ran in 12-14 seconds (no noticeable delay added). #275
Now let’s be serious. If you have 600 models in your DbContext, you have bigger problems than dealing with startup time. But regardless, this should be beneficial even if you have a limited number of models.
DefaultDbModelStore
There is a DefaultDbModelStore which comes in the box that compares the timestamp between the assembly (dll) of your context against the edmx. If they do not match, the edmx (cache) is deleted and rebuilt.
DbConfiguration
If you’re unaware of the DbConfiguration, take a look at the docs. But the gist is to define the model store you want to use the in DbConfiguration using the new SetModelStore.
What this will do, is create the edmx files for your DbContext(s) in the direction where the application is executed. Example while debugging the file generated would be be /bin/Debug/MyAssembly.MyNamespace.MyDbContext.edmx
Feedback
Love hearing your comments, please leave them bellow or on Twitter.
Except when you run your application with IIS (also in development) the current directory is c:windowssystem32inetsrv where your app will not have write permissions. So a better solution is to use:
var path = Path.GetDirectoryName(this.GetType().Assembly.Location);
SetModelStore(new DefaultDbModelStore(path));
which will point to the ASP.NET Temporary Folder for the application when running in IIS or the “current” directory in f.ex a Console/Windows application.
Thanks! I’ll update the post. This is a really good point that I never noticed as I’m using self host via Katana/Owin so I never noticed.
Thanks Derek/Jonny. The Path.GetDirectoryName(this.GetType().Assembly.Location) worked for me also.
Nice to have the performance improvement… but the DefaultDBModelStore is error prone. Lets say I have v1 of an app but don’t run it.
v2 is released and the dll time stamped but I don’t run v2 either. I then run v1 which creates an edmx file with a time stamp newer than the v2 dll time stamp. When I finally get around to it and upgrade to v2… it won’t update the edmx file and my model will be out of sync.
Great observation due to it using timestamp of the assembly/dll of the context. In this situation related to deploying to production, it would probably be wise to either:
-Build the EDMX in your CI/Build process and include it in your deployment package.
-Do not turn on the model store for production
-Remove any edmx in your production deploy location if you are going to use the model store.