We have a situation, where a team of developers started working on a project with EF code first and originally the automatic migrations were enabled. Now we need to sort out the mess, turn off automatic migrations, reset everyone's migrations history and 'start anew', forcing all developers to use manual, code-based migrations from now on.
I have been following this answer to clear the migrations history (which worked so far):
EF - Moving from AutomaticMigrations to Manual Migrations
In the meantime we would like to automatise the application of the code-based migrations in the deployment process.
For that, I have been playing around with migrate.exe as described here:
http://msdn.microsoft.com/en-gb/data/jj618307.aspx
We have a DAL project that hold all the data objects and deals with migration.
I have copied migration.exe from /packages/EntityFramework.5.0.0 to DAL/bin/Debug.
I have updated my DB to the latest, then cleared my migrations history table.
I changed a StringLength attribute in one of my models and run add-migration test.
Now, I have exactly 2 code-based migrations in my DAL/Migrations folder: one for the initial create, and one for modifying the column that I've changed. (they both have their .resx and .Designer.cs brothers)
I am trying to run migrate.exe to apply the last migration (test) like this:
migrate.exe MyApp.DAL.dll /startupConfigurationFile="..\..\app.config"
It runs, then it prints
No pending code-based migrations.
And then fails, because it wants to run an automatic migrations, and fails, because it is turned off. (which is ok, 'cause I don't want automatic migrations)
For some reason migrate.exe does not see my code-based migration files.
What am I doing wrong?
(If I try to apply the same migration from PM console, that works)
Related
I am using Entity Framework 6.1.3 Data migrations along with code first.
I am in the process of resetting the migrations. I have deleted the migrations history table and created a new baseline snapshot of the current state of the db. Everything works fine on a new install with the following intializer:
Database.SetInitializer(new MigrateDatabaseToLatestVersion<T>, Migrations.Configuration>(true));
However, how should one deploy this reset to our customers who have an existing database? This fails locally when i have an existing db with the error:
There is already an object named '*****' in the database.
Does anyone have a better approach when needing to reset migrations and synchronizing schemas of existing databases?
I set out thinking I needed to reset my migrations because previous developers on my team were not using the Add-Migrations script correctly. This was causing the following error:
However, I wasn't sure how that would work out for existing customers. I didn't realize that I was able to re-scaffold my migrations. After much SO searching and trial and error, I was able to save my migrations. I first migrated to a migrations that was in a good state.
It was important to use the fully qualified name given. After trial and error I found a stable migration. I verified this by running the following:
It would succeed if EF could fully reconcile. I also had to exclude from VS project, all the migrations following the recently targeted migration. Simple shift select, right click and exclude from project.
Then I added the next migration back to the project after i updated the database. I also used the fluent API to exclude all the model changes following the currently targeted migration.
Then I incrementally re-scaffold all the broken migrations.
Then at the very end I created an idempotent script of my schema up to this point. Using the following:
My migrations are now not complaining about model mismatch and I am happy.
In Entity Framework 6 I'm using the Update-Database command to apply migrations. I've got three environments that I juggle (DEV, QA and PROD), and upgrade them using
Update-Database -ConnectionStringName DEV
But, now I'd like to know which migration my PROD environment is at, and which migrations willl be applied if I call Update-Database.
Is there a command for checking which migration is the latest one applied, and which will be applied if I run Update-Database?
To see which migrations have been applied to the database use the command Get-Migrations:
Get-Migrations -ConnectionStringName PROD
You can also check the contents of the table __MigrationsHistory in the right database. It contains info about all migrations applied to the database.
The next migration applied depends on the existing migration files in your project. A migration file name includes a prefix that is a timestamp, which specifies the time at which the migration file was generated (unless you used the -force parameter that might cause to reuse an existing migration file keeping its existing timestamp string). The migrations are applied according to that timestamp. So the alphabetical ordering of your migration files indicates the order in which they are applied.
A safe way to check which migration will be applied next is to run Update-Database with the -Script parameter, which generates the SQL script for the migration but does not run it. So you can see which migration would be applied if you run the real Update-Database.
Update: in Entity Framework Core this command is not available. You can still check __MigrationsHistory table contents. To generate the SQL script that would be executed without running it you can use the command Script-Migration.
In my project I have dozen+ migrations. http://screencast.com/t/CA2kZk3WCFj
But when I try to create database from scratch EF only starts from the marked migration to the bottom.
if I enter command:
update-database -targetMigration InitialCreate
this is the response:
he specified target migration 'InitialCreate' does not exist. Ensure that target migration refers to an existing migration id.
How can I resolve this issue and make EF see all of the migrations?
This can often happen if you use the Update-Database command in Release mode. Running in Debug mode seems to work ok.
I had the same problem.
In my case, the "ignored" migrations were not in the same namespace (caused by a project renamed).
I frequently encounter the following situation with Entity Framework code first migrations. I add some migrations and update the database with them successfully. When later I wish to add a new migration, the Add-Migration command complains that its "Unable to generate an explicit migration because the following explicit migrations are pending...". I.e., it seems to forget that its already applied those migrations previously and therefore they shouldn't be now considered as pending. If I try to workaround this issue, Update-Database indicates "Unable to update database to match the current model because there are [new] pending changes...". I don't understand why EF migrations getting out of sync since I'm only making changes to the model.
For me the issue was that we had renamed the namespace of the migration 2014123456_Initial.cs.
But VS had not regenerated the namespace in its associated 2014123456_Initial.Designer.cs.
Once the Designer.cs was changed to use the same namespace, it all started working again.
I was having the same issue and the solution was:
Clean solution;
Build the project which has migrations enabled (just to make sure);
Build the Solution again;
This is pretty much equivalent of using the Rebuild Solution option in the Build menu.
I had the exact same problem and could not resolve it.
To add to IamDOM solution ALSO add an empty migration and update database.
For example:
Add-Migration Test
Update-Database
It worked for me few times now.
I found that VS had got confused somehow and not actually added the migrations to the .csproj. Closing, re-opening VS then re-including the migration in the project and saving-all worked.
I work on a team of 4 developers using EF5, everyone working on their own local database. Up until now we've been using automatic migrations but we're nearing the point where we need to release to production so we've disabled automatic migrations and started adding explicit code-based migrations.
Here is the problem: I ran the Update-Database command after a developer created a new explicit migration and I get the following error:
Applying code-based migrations: [201209080142319_CreatedDate.LastModifiedDate.Additions].
Applying code-based migration: 201209080142319_CreatedDate.LastModifiedDate.Additions.
Applying automatic migration: 201209080142319_CreatedDate.LastModifiedDate.Additions_AutomaticMigration.
Automatic migration was not applied because it would result in data loss.
Why do I get this error even though I've disabled automatic migrations? I can fix this error by deleting the explicit migration and then re-scaffolding it (running Add-Migration). Then Update-Database runs fine and doesn't mention anything about 'Automatic migration...' Also, the code in the migration created by me when I run Add-Migration is identical to the one created by my teammate. I don't see why it would even try to do an automatic migration since AutomaticMigrationsEnabled = false;.
What am I missing here?
I hate to answer my own question but I encountered this problem again. A developer on my team re-enabled automatic migrations on their local machine and then created an explicit migration, which reproduced this behavior as soon as I ran it.
Entity framework will always run an automatic migration before it runs an explicit migration that has the Source property defined in its .resx file, even if AutomaticMigrationsEnabled = false. An explicit migration will only have the Source property set if it is created after an automatic migration has been run.
The upshot is that disabling automatic migrations only means that EF won't automatically upgrade your schema when it detects model changes - but it might still do an automatic migration if it needs to fill in a gap between some explicit migrations. To avoid this behavior, don't use a mixture of automatic migrations and explicit migrations.
public class Configuration : DbMigrationsConfiguration<bailencasino.com.dal.Context.BlncnoContext>
{
public Configuration()
{
AutomaticMigrationsEnabled = false;
AutomaticMigrationDataLossAllowed = true;
}
Add AutomaticMigrationDataLossAllowed = true; so you assume that you want to allow EF to add remove SQL objects that result in data loss.
My team has experienced something that may be related to this. If two team members both add a migration, check in their code, get latest, and then perform update-database, the second one will get an error because there is a migration "skipped" - their system sees the team member's migration was never implemented.
We've started checking everything in and getting latest, doing the update-database (if a team member added a new migration), then doing add-migration, update-database, check-in.
AutomaticMigrationEnabled = false prevents your application from updating the database on its own.
But since your running Update-database yourself, Update-Database checks the current state of the database and then runs all the migration steps not already in the database including the changes in the model (dbContext) that do not have a code-based migration yet.
My guess is that there is a change in the model that would cause data loss.
You can use the -force parameter to apply the changes still when there is data loss.
#Dave Graves is right. I had the same issue and did his fix in order to disable the auto migration of particular migration file
heres some instructions:
go to where your migration files are located in solution explorer (if you are using visual studio)
look for the migration file causing that auto migration e.g: 202008181102535_BlogPost.cs
expand it and you will see its designer file. open that file
inside that file, you will see the Source property of it is being set by something like Resources.GetString("Source"). replace that with null and then try again to manually execute update-database in your package manager console.