I'm using entity framework version 6.1.3 and .NET Framework 4.0.
I'm trying to use Migrations from Code-First from existing Database.
I'm having a trouble that whenever I use the Update-Database it makes the changes from my migration, and changes my database, but it keeps the migration as "Pending" and when I try to add another migration with Add-Migration, it says I have pending migration.
Example of the problem:
Run the Enable-Migrations command from the Package Manager Console.
Run the Add-Migration first command to create an initial migration.
Remove all the code in Up() method for the initial migration, because I don't want to create the tables that already exists.
Run the Update-Database command to apply the initial migration to my database (it runs successfully).
Make changes to my code-first model (add column to existing table).
Run the Add-Migration second command to create a new migration.
When I run step 6, I get the following error:
Unable to generate an explicit migration because the following explicit migrations are pending: [201601111013546_first]. Apply the pending explicit migrations before attempting to generate a new explicit migration.
If I delete the migration "[201601111013546_first]" from my Migrations folder, I can run step 6, and use the Update-Database, and it successfully changes my database, adding the column I wanted, but if I change my model again and use Add-Migration third, it says the same error, that the second migration is still pending.
Also, if instead of steps 5 and 6, I just run Update-Database again, it runs the same script returning the obvious error of already having a 'MigrationId' in the table dbo."__MigrationHistory":
ERROR: 23505: duplicate key value violates unique constraint "PK_dbo.__MigrationHistory"
I already tried:
Create a new project (ConsoleApplication) and made the same steps getting the same errors.
Delete entire Migration folder and run Enable-Migrations again.
Verify the namespace of the Migration and it's .Designer file.
I have only one connectionString but still tried the commands with -ConnectionStringName.
Any suggestions?
Thanks.
I am currently playing with beta4 of EF7 using the blank ASP.NET web project template.
After having kicked off the existing migration, resulting in the tables being created in the localdb, the following occurs:
Strangely, when I clean up the migration-folder, including removing ApplicationDbContextModelSnapshot.cs and I run
dnx . ef migration add twice, I get the following error:
dnx : System.InvalidOperationException: No data stores are configured. Configure a data store by overriding OnConfiguring in your DbContext class or in the AddDbContext method when setting up services.
The second migration is not created. When I review the created migration it contains all tables whereas the database is already provisioned, so you should expect the migration being empty.
Then, when I remove the first migration and run the add migration command again more than once, all the migrations are correctly created, i.e. as empty files.
Can someone explain this to me? Is this expected behavior or is this a bug in beta4?
Tip for people coming from former EF-versions:
* Don't use the K command framework anymore.
* Don't use the Add-Migration cmdlets anymore.
Both have been replaced by dnx . (dot). (dnx = .NET execution environment)
Some references:
https://github.com/aspnet/EntityFramework/wiki/Entity-Framework-Design-Meeting-Notes---September-11,-2014
http://jameschambers.com/2015/05/project-k-dnvm-dnx-dnu-and-entity-framework-7-for-bonus-points/
Remove the constructor of ApplicationContext. It is a temporary workaround to enable deployment, but it interferes with the Migrations commands.
I am using Beta 3 of EF power tools for EF5.0 to reverse engineer an existing database.
When I select "Reverse engineer code first" from the project context menu, I get all the models and the DBContexts + mapping as expected. And all looks good.
I enabled Migrations successfully immediately after the reverse engineering process completed.
However I want to add a new property to one of the models. After adding the new property,
I run PM> Add-Migration AddMyPropertyToMyTable
a Migration file is created,
If I then try PM> Update-Database
I get an error telling me that the tables already exist.
I am following the tutorial here:> http://msdn.microsoft.com/en-us/data/jj200620
Why am I getting this error? of course the table exists, I just reverse engineered it
Am I supposed to delete the database after reverse engineering? Or in the case of a reverse engineered Db, do I have to make my changes to the actual database and just reveres engineer it again to get the desired changes in my project (so what's the point of reverse engineering in the first place?)
is there something missing from the tutorial, i.e. an extra step required to make the database updateable after model changes?
When you enabled migrations with the existing database, EF didn't add the __MigrationHistory table or initial migration (DbMigration) file.
You can add an initial migration by using the following in the package manager console:
Add-Migration Initial -IgnoreChanges
This will be an empty initial migration. Then to force EF to create the __MigrationHistory table, you can use:
update-database
This should then create the __MigrationHistory table (under System Tables)
You should now be able to make model changes, and create new migration files (or use automatic migrations by configuring it in your Configuration.cs file under the Migrations folder).
You can run these migration changes by hand by using update-database, or have the database automatically migrated to the latest migration on application startup by using the MigrateDatabaseToLatestVersion initializer.
You can set this in the app.config/web.config so that it isn't set in production for example.
Using Entity Framework 5 code first, I'm wondering how EF Migrations decides that the target database is at a certain migration version? That is, I've emptied my database (deleted all tables) and am trying to re-do the initial migration via the following command (in the PM console): update-database -targetmigration 201212011907118_Initial. update-database then responds with 'Target database is already at version 201212011907118_Initial'.
Apparently, Code First Migrations maintains a table called 'dbo.__MigrationHistory' in which it stores metadata about applied migrations. This is a system table, which makes it difficult to e.g. delete. See this post for reference.
I'm trying to get Entity framework migrations working. I've enabled code first migrations, its created a migrations folder, config file and the mig history table, but no initial create. Am i missing a step? This is a new db created by EF (4.3.1).
This behavior is not in place by default, but it is available to you easily in many different forms.
You can call context.Database.CreateIfNotExists(); at application startup.
You can use one of the built-in DatabaseInitializers. The CreateDatabaseIfNotExists initializer is built into EntityFramework and just needs to be added to your project.
You could create your own custom database initializer which includes option #1 inside of itself. Example: Code First Migrations and initialization
You can include DatabaseInitializers in your project either by code or via a config file.
Include an EntityFramework Database Initializer via code:
In your application startup you can setup the DatabaseInitializer like so:
System.Data.Entity.Database.SetInitializer<DairyMmmContext>(new System.Data.Entity.CreateDatabaseIfNotExists<DairyMmmContext>());
NOTE: this code has changed multiple times throughout the life of entityframework! This example is for EF 4.3 which is the current production release available via nuget.
Include an EntityFramework Database Initializer via configuration element:
<configuration>
<entityFramework>
<contexts>
<context type="MyNamespace.MyEFDataContext, AssemblyName">
<databaseInitializer
type="System.Data.Entity.CreateDatabaseIfNotExists`2[[MyNamespace.MyEFDataContext, AssemblyName],
[MyNamespace.Migrations.Configuration, AssemblyName]], EntityFramework" />
</context>
</contexts>
</entityFramework>
</configuration>
You'll notice this can be a little "ungraceful" with this configuration. You need to replace AssemblyName above with the name of the assembly you keep your entityframework stuff in, replace MyNamespace.MyEFDataContext with the fully qualified name of your entityframework data context, and replace MyNamespace.Migrations.Configuration with the fully qualified name to your configuration class (by default in the Migration folder inside your project).
EDIT: Edited to respond to additional comments
A migration is a change from one schema definition to another schema definition. Creating the empty database is not a migration (but everything after that is). There will be no migration source file in your project for just creating an empty db, that is done in code by the initializer.
If you are already using the DropCreateDatabaseAlways initializer it should be doing that. However, I noticed you are setting the initializer in code which means there is the opportunity for a timing problem (setting the initializer after your context is already past the point of calling any initializers).
You can force entityframework to run your initializer at any point in code with context.Database.Initialize(true); (The parameter is a true/false to force the initialization regardless of the current state). That would drop and recreate your database every time.
But you can also just make sure your initializer is setup as early as possible in your application's life cycle (before you have created a single instance of your context).
"Initial Create" is NOT created automatically! You need to create that yourself. Some tutorials of EF are confusing and I had the same misunderstanding as you.
What you need to do:
-Add-Migration InitialModel
If you already have created your database tables and domain model, then:
-Add-Migration InitialModel -IgnoreChanges
From this point, your code will be in sync with database. Anytime you change the code, you can use Add-Migration to add the changes to your database.
The article / tutorial here here (on microsoft.com)
describes the reason that an initialCreate migration doesn't exist. The migration will only be added if the Database already exists. Otherwise, the first migration will be the 'initialCreate' as there is no point in creating a migration to a Database that doesn't exist yet... no DB means there is nothing to roll back to, on a down migration.
Here is the pertinent paragraph:
Run the Enable-Migrations command in Package Manager Console
This command has added a Migrations folder to our project, this new folder contains two files:
The Configuration class. This class allows you to configure how Migrations behaves for your context. For this walkthrough we will just use the default configuration.
Because there is just a single Code First context in your project, Enable-Migrations has automatically filled in the context type this configuration applies to.
An InitialCreate migration. This migration was generated because we already had Code First create a database for us, before we enabled migrations. The code in this scaffolded migration represents the objects that have already been created in the database. In our case that is the Blog table with a BlogId and Name columns. The filename includes a timestamp to help with ordering.
If the database had not already been created this InitialCreate migration would not have been added to the project. Instead, the first time we call Add-Migration the code to create these tables would be scaffolded to a new migration.
Not sure it's the same but I had a similar issue. I think my problem was related to the fact that I dont use a connections string from the config file to get my connection string.
Fiddling with the start up project in the solution and also the projet combo in the Package Manager Console I was able to generate that first migration.
Also make shure you have a connections string with the name of your dbContext class so the Package Manager can find it.
I am using EF 6 RC1 and ran into this problem where neither the InitialCreate nor __MigrationHistory were being created when running Enable-Migrations.
Actually, just after upgrading from EF 5 to EF 6 I ran Enable-Migrations and for some reason it created a __MigrationHistory table using the EF 5 schema, so I deleted it and my Migrations directory and tried to start over.
But every time I deleted the Migrations directory it wouldn't create an InitialCreate or __MigrationHistory. I tried dropping and recreating the database and restarting Visual Studio 2012 to no avail. I gave up for the day and the next morning tried again - after letting my computer sit for about 8 hours it then created the InitialCreate. I am guessing there must be a cache somewhere that has a really long timeout - anyone? I am also guessing that rebooting might clear the cache, but I didn't try that.
Whatever the case, it is possible to use PM> Add-Migration InitialCreate to do that step manually.
Anyway, I still didn't get a __MigrationHistory table. Apparently, EF 6 has changed from creating it during the Enable-Migrations command to instead only creating it during the Update-Database command. And since my schema had already been created at that point, I needed to tear it down and recreate it manually:
PM> Update-Database -TargetMigration:0
PM> Update-Database
I also stopped after the first command to check the state of the database to ensure I was updating the correct one, since according to this, the database connection string is picked up or autogenerated depending on the configuration, and unless it is configured right, there is no guarantee you are going to access the database or instance of SQL Server you intend to.
After running both commands it created a __MigrationHistory table - and it didn't create it as a system table (which I didn't really want anyway), so all is good. Not exactly the same problem as the OP, but hopefully this will be helpful to someone else.
References:
http://elegantcode.com/2012/04/12/entity-framework-migrations-tips/
Reset Entity-Framework Migrations
How to recreate migrations from scratch
I know this is old, but there is no accepted answer and I had same issue.
The trick is Enable-Migrations command. As stated here there is a command Enable-Migrations –EnableAutomaticMigrations. What it does it starts migrations exactly where you are.
If you want the first migration to be creation of database, just run Enable-Migrations (without --EnableAutomaticMigrations).
And remember to set initializer:
Database.SetInitializer(new MigrateDatabaseToLatestVersion<LicenseContext, Configuration>());