Develop Reference

Code First Update Database Error 'ApplicationDbContext' context has changed

I am using MVC 5 and EF 6 with Code First. I got this error every time I tried to log in:
The model backing the 'ApplicationDbContext' context has changed since
the database was created. Consider using Code First Migrations to
update the database (http://go.microsoft.com/fwlink/?LinkId=238269).
This program is ok for 2 years in development until this strange error come this week. Normally after we change the model, we just simply update-database and everything ok. Today we try to do the same and no error returned :
PM> update-database
Specify the '-Verbose' flag to view the SQL statements being applied to the target database.
No pending explicit migrations.
Applying automatic migration: 202012212240459_AutomaticMigration.
Running Seed method.
PM>
We are using automated migration. But i just try to add migration manually and update-database again successfully but still returning same error.
We tried to remove the database and recreate again using update-database and a new database created, create a dummy account but still returning the same error. Tried following and checking some suggestions in other threads and still not get a good result. Deleting migration history solved the error but when we update-database for future update it will create a duplicate error, so this is not counted as a solution. I don't know what to debug anymore and what to check. Any help is appreciated. Thank you.

I think; you change your entity class,
1 - Check your entites
2 - Check your DbSet in Context class
4 Check you entity frame work version
3- remove last migration and re install

Entity Framework sometimes doesn't recognize past migrations after DB restore

Recently, I've started to experience an issue with EF.
Intermittently, I will copy a DB and restore it for testing, and EF will fail to recognize many of the previous migrations.
Get-Migrations will return a list of half or so of the applied migrations. If I check the _MigrationHistory table in the restored DB, I will find every migration that I expect to see in the table.
If I try to execute Update-Database, EF will try to start applying all migrations from the point where Get-Migrations leaves off, until the last migration is applied. Because all of these migrations have already actually been applied; this fails because the migrations don't match the current scheme of the DB anymore.
What's going on? Has anyone experienced this before? What can I do to make EF recognize all the other applied migrations? Removing all the past migrations and creating a new initial migration isn't an option. I need to try and fix the state of EF.
Note: this doesn't always happen, it appears to happen intermittently, after a DB restore. Sometimes dropping the restored DB and trying again manages to fix it. This hasn't happened in Production yet but I'm concerned it will.
I've tried doing some googling on this issue but all I seem to find are people asking how to migrate or how to reset migrations. I'm looking for a way to fix EF's state so it recognizes all the Migrations found in _MigrationHistory. Thanks for your time!

So... ultimately this was user error, but the problem was very strange so I'll answer my own question to help others in the future. Short story: trust EF to do the right thing. You probably messed something up.
Basically what I found out is I wasn't connecting to the database that I thought I was connecting to. I had a typo in my connection string, and this caused EF to create a new DB and partially perform all of our ancient, 4 year old migrations. It would fail part-way through because one of these old migrations referenced files that aren't a part of the solution anymore.
Sequence of events:
Opened Sql Studio Management Studio (SSMS)
ran a TSQL script to copy the database with a new name
(note: at this time, there are 2 databases now in my SSMS, the original and the copy)
Change the connection string in my project to the new database
(note: this is where I introduced a typo in the connection string)
Ran the program - started getting "model has changed, please run update-database" error messages.
Ran get-migrations -verbose, which only returned some of the applied migrations and the connection string it outputted looked right to me.
Checked the new DB in SSMS and found it was full of data and had all migrations applied
(note: SSMS still only showed 2 Dbs)
It was about this time that I came here and started posting. #SteveGreene suggested I try generating the SQL script... I did and copied it into SSMS on the new db and found it was able to find the latest migrations... but this didn't correlate with how get-migrations was behaving.
This is when I refreshed my SSMS object explorer. That's when the 3rd DB suddenly appeared, and I figured out that it was created when I introduced a typo in my connection string. The project is configured to run migrations automatically, so this caused a 3rd db to get created and execute all of the old migrations... one of which referenced a file that isn't in the solution anymore and failed. I checked the third DB and it had no data and only some of the migrations applied.
All I had to do was delete the extra DB and fix the typo in my connection string...

Do I need a migration for EF code first when the database does not exist in SQL Azure?

I have tried lots of variations of EF migration v6.0.1 (from no database, to empty databases to existing databases) and I have a particular problem with Azure DB instances not being able to correctly be created on first deploy using Octopus deploy.
There are a number of places where this could be going wrong, so I thought I would check some basics of EF Code First migration with you fine people if I may:
If I create a code-first model, and know that the database does not exist in the intended target database server on Azure. With the default of 'CreateDatabaseIfNotExists' approach and with AutomaticMigrations disabled;
If I then call 'migrate.exe' with the assembly containing my DbContext and migration Configuration will I get a new database created with the current state of the model? or will I get a new database with nothing in it? i.e. do I need to explicitly 'add-migration' for the initial state of the model?
I have read in the documentation that the database instance should be created automatically by the migration process, but no one states clearly (at least to me) that this newly created database will be generated with the current model without a formal 'initial state' migration created.
So the question is this: do I need an explicit migration model generated for migrate.exe to work from?
Through whatever means I try, I get a database but the application launches with the unfriendly message "Model compatibility cannot be checked because the database does not contain model metadata. Model compatibility can only be checked for databases created using Code First or Code First Migrations." Remembering that this is the same application library that just created the database in the first place (from scratch) I fail to understand how this has happened!
I did manually delete the target database a few times via SQL Server management studio, is this bad? Have I removed some vital user account that I need to recover?

Migrations and the Database Initializer CreateDatabaseIfNotExists are not the same.
Migrations uses the Database Initializer MigrateDatabaseToLatestVersion, which relies upon a special table in the database _MigrationsHistory.
By contrast, CreateDatabaseIfNotExists is one of the Database Initializers which relies upon the special database table EdmMetadata. It does exactly as it implies: Creates a database with tables matching the current state of the model, i.e. a table for each DbSet<T>, only when the database does not exist.
The specific error you have quoted here, Model compatibility cannot be checked because the database does not contain model metadata., occurs due to the existence of DbSet<T> objects which were added to the code base after the initial database creation, and do not exist in EdmMetadata.
There are 4 basic Database Initializers available, 3 of which are for use when migrations is not being used:
CreateDatabaseIfNotExists
DropCreateDatabaseWhenModelChanges
DropCreateDatabaseAlways
Also note, the 4th Initializer, MigrateDatabaseToLatestVersion, will allow you to use Migrations even if AutomaticMigrations is disabled; AutomaticMigrations serves a diffierent purpose, and does not interact with the Database Initializers directly.
If you intend to use Migrations, you should change the Database Initializer to MigrateDatabaseToLatestVersion and forget about the other 3. If, instead, you intend to not use Migrations, then the choice of Initializer is situational.
CreateDatabaseIfNotExists will be more appropriate when you are certain that your data model is not undergoing active change, and you only intend to be concerned with database creation on a new deployment. This Initializer will elp ensure that you do not have any issues with accidental deletion of a database or live data.
DropCreateDatabaseWhenModelChanges is most appropriate in development, when you are changing the model fairly often, and want to be able to verify these changes to the model. It would not be appropriate for a production server, as changes to the model could inadvertently cause the database to be recreated.
DropCreateDatabaseAlways is only appropriate in testing, where your database is created from scratch every time you run your tests.
Migrations differs from these 3 Database Initializers, in that it never drops the database, it instead uses Data Motion to execute a series of Create Table and Drop Table SQL calls.
You also can use Update-Database -Script -SourceMigration:0 in the Package Manager Console at any time, no matter which Database Initializer you are using, to generate a full SQL script that can be run against a server to recreate the database.

Firstly, many thanks to Claies who helped me get to the bottom of this problem. I have accepted his answer as correct as ultimately it was a combination of his response and a few additional bits of reading that got me to my solution.
In answer to the actual posts question 'Do I need a migration for EF code first when the database does not exist in SQL Azure?' the answer is yes you do if you have disabled automatic migrations. But there is a little more to be aware of:
The Azure aspects of this particular problem are actually irrelevant in my situation. My problem was two-fold:
The migration being generated was out of sync with respect to the target model. What do I mean? I mean, that I was generating the migration script from my local database which itself was not in sync with the local codebase which created a migration that was incorrect. This can be seen by comparing the first few lines of the Model text in the __MigrationHistory. This awareness was helped by referring to this helpful post which explains how it works.
And more embarrassingly (I'm sure we've all done it) is that my octopus deployment of the web site itself (using Octopack) somehow neglected to include the Web.Config file. From what I can tell, this may have occurred after I installed a transform extension to Visual Studio. Within my nuget package I can see that there is a web.config.transform file but not a web.config. Basically this meant that when the application started up, it had no configuration file to turn to, no connections string at all. But this resulted in the slightly misleading error
Model compatibility cannot be checked because the database does not
contain model metadata.
Whereas what it should have said was, there isn't a connection string you idiot.
Hopefully this helps people understand the process a little better after reading Claies answer and also that blog-post. First though, check you have a web.config file and that it has a connection string in it...

Moved Database to a new server now entity website doesn't work

We moved the database 2008 to 2012 and moved it to a new server.
Now when running the website I get the following error:
The model backing the 'DocumentDBContext' context has changed since the database was created. Consider using Code First Migrations to update the database (http://go.microsoft.com/fwlink/?LinkId=238269).
I have gone through several of the similar answers but none seem to work.
No changes were made to any of the tables so the tables should match the models 100%.
What is the quickest way to get this to start working again?
I am using Entity Framework 5.0

I've seen this message several times. And it exactly means that the database changed. Run Update-Database -Verbose (and optionally -Force switch) to update the database. This worked for me every time.
For more info see here: Code First Migrations

Entity Framework Code First on external SQL server

I'm following the Entity Framework tutorial on:
Link
I've downloaded the source code, and ran. The project works fine (using the default connection string).
<add name="SchoolContext" connectionString="Data Source=|DataDirectory|School.sdf" providerName="System.Data.SqlServerCe.4.0" />
Next i've changed the connection string to connect to a remote server (which successfully connects). However the tables aren't created and when running the application and accessing the controller I get the following error.
Error:
Model compatibility cannot be checked because the database does not contain
model metadata. Model compatibility can only be checked for databases created
using Code First or Code First Migrations.
My database user is 'dbowner' so I wouldn't imagine it's database access issues.
I'm new to EF, and don't know much about Code First Migrations. Have you come across the above error, and would Code Migrations solve this issue? If so why?

From my reading (please correct me if I am wrong) the scenario here is that you have an existing (perhaps empty) database on a remote server that you wish to put your EF code-first work into.
The error is coming about because, I think, EF is looking for a _MigrationHistory table (metadata about what EF code-first migrations have been run against it etc) and can't find it. There is some reasonable coverage of this table here for some background/interest reading.
So to resolve the issue, I think the steps to take are:
Initialise your database so that it acknowledges the EF code-first stuff
Update the database, rolling forward all your migrations to date
I found some good coverage of how to do this here. This blog also has some good coverage of EF topics in general
PS. I am guessing that your .dsf/SQL Compact Edition database wouldn't have had this problem because EF code-first would have created it for you on first run so it was already acknowledged as being a code-first database.

Here is a link to Entity Framework Power Tools. It is made for creating models by 'Reverse Engineering' your Database on a remote server. You can then easily access this database using EF.
Reverse Engineer Code First - Generates POCO classes, derived DbContext and Code First mapping for an existing database

Both of the initializer methods which I had tried fail when the database already exists:
Database.SetInitializer<Context>(new Initializer());
Database.SetInitializer(new DropCreateDatabaseIfModelChanges<Context>());
However it is possible to force the database to be dropped using:
Database.SetInitializer(new DropCreateDatabaseAlways<Context>());
The following SO post provides the answer to my question:
Setting up a Entity Framework Code First Database on SQL Server 2008
I've tried a combination of the two, and have decided that the best solution is to manually go into SQL Management studio and DROP the database, and re-create it using the initializer as this allows me to Seed the contents of the database.
Database.SetInitializer<Context>(new Initializer());
See here for more information on Seeding the database as it is also quite an unstable processess!
How can I get my database to seed using Entity Framework CodeFirst?