I have an existing SQL database application that was encoded using the first database model (I create an EDMX file every time I have a schema change).
Additional development was done (Windows services that support the source application), which uses EF POCO / DbContext as the data layer instead of the EF EDMX file. Initialization parameters were never configured in DbContexts, but they never changed the database, because DbSet objects always corresponded to tables.
Now I have written a separate application that uses the existing database, but only its own new tables, which it creates using the EF initializer. I thought it would be great to use EF Code First to manage these new tables. Everything works fine when I first run the application, but now I get this error from some of my original EF POCO DbContexts (which never used an initializer).
The model supporting the "ServerContext" context has changed since the database was created. Consider using First Code Migrations to update the database
After some research, I found that EF compares the hash of its schema with some stored hash on the sql server. This value does not exist until the context actually used the initializer in the database (in my case, until the last application added its table).
Now my other DbContexts throw an error when they read an existing hash value and do not match its own. An EF connection using EDMX has no errors.
It seems like a solution would be to put this line in protected override void OnModelCreating(DbModelBuilder modelBuilder) in all DbContexts experiencing the problem
Database.SetInitializer<NameOfThisContext>(null);
But what if later I want to write another application and create my own tables again using EF Code, now I can never reconcile the hash between this theoretical and newer context and what is causing now.
Is there a way to clear the hash that stores EF in the database? Is EF smart enough to only modify tables that exist as DbSet in the current context? Any ideas were appreciated.