Search code examples
entity-frameworkef-code-firstsql-server-cedatabase-performanceef-power-tools

Start-up Performance Issues with Entity Framework, SQL Server CE 4.0 and Code First

I am using Entity Framework (EF) 5.0, Code First approach, and SQL Server CE 4.0 database in my application. However, I am facing a major performance problem on application start-up.

I searched on the Internet and found this article which explains which operations affect start-up performance, and one of them is view generation. So, I looked into how I could generate views at compile time and link them to EF at run-time instead of creating views at run-time. I came across Entity Framework Power Tools which provides a command to generate views through your DbContext class.

I have generated the views at compile time using Entity Framework Power Tools as described in this article. However, when I run my application with SQL Server CE it always generates the following exception:

The mapping and metadata information for EntityContainer 'DatabaseContext' no longer matches the information used to create the pre-generated views.

whereas the same application works fine with SQL Server database. So, I searched more but have not found a fix to this problem. Following are links where people have reported similar performance problems:

  1. MSDN Blogs
  2. Entity Framework forum on MSDN

My question is this: "Is there a workaround or solution for this application start-up performance problem?". I need to use SQL Server CE and not SQL server.

Solution

  • Actually EF Power tools were generating the view using the default provider SqlClient but, I needed to generate the views for SqlServerCe.4.0 provider which, I was unable to figure out why every time generated views goes out of date and finally I figured out why it was not working.

    So, I just commented the DbContext constructors from my context class and, then I ran the "Generate Views" and "View Entity Data Model XML" command of EF power Tools, then EF Power Tools took the connection string from App.config otherwise it uses a default connection string that connects to Sql Server with SqlClient as provider.

    So, I believe that if anybody uses any other provider like Devart's Oracle provider etc., then he/she needs to generate the views by specifying the connection string and provider information in App.config (for desktop applications) or web.config (for web applications) and comment out the DbContext constructors (or hide it from EF Power Tools using per-processor).