I have set up a simple Migration with AutomaticMigrationsEnabled = false. Everything works great from visual studio or when using MigrateDatabaseToLatestVersion.
However, this is not ideal for me. I would like to run migrations from a deployment script on my ci server. I found this article explaining how to do this using migrate.exe but this seems to always run the seed. This is even when there are no migrations to apply.
Do I need to check programmatically within the Seed method whether any migrations have been run? How do I do this?
Use DbMigrator to manually run Update() only if there are pending migrations. It was introduced in Entity Framework 5.0.
private void MigrateAndSeedDbIfSchemaIsOutdated()
{
// Disable initializer.
Database.SetInitializer<MyContext>(null);
// Make sure database exists.
using (var db = new MyContext())
{
db.Database.Initialize(false);
}
var migrator = new DbMigrator(new MyConfiguration());
if (migrator.GetPendingMigrations().Any())
{
// Run migrations and seed.
migrator.Update();
}
}
Related
Our app runs on Azure with read/write permission on the DB. We are not nuts about enabling EF's automatic migrations for a production application, and because the DB user account isn't owner, it doesn't have permission to run migrations anyway.
I have used with a script to run migrate.exe to apply migrations in the past, and was happy with the result. Is there a way to accomplish this on an azure app service?
Currently running the migrations right from visual studio.
One option would be to use a Web Job to run your migration script on a schedule, or on-demand:
Web Job overview
You'd probably want to set up a CI deployment so that the current EF migration script is available to the job:
Web Jobs + CI
And more info
Have a good backup strategy in place for your database, so you can smoke test completed migrations in a staging environment (preferably in an automated fashion) before flipping it into production.
Good luck!
What I ended up doing is making a small console application as a web job, which I set up to be manually triggered. This ensures that my migrator.exe gets built and placed in a place I know.
public static void Main(String[] args)
{
Log("Starting");
var cs = GetConnectionString(args);
if(String.IsNullOrEmpty(cs))
{
Log($"Connnection must be passed as a command argument, or in the environment variable {ConnectionStringVar}, or in the appSetting {ConnectionStringVar} (in that order).");
Log("Exiting without running migrations.");
return;
}
try
{
var c = new Configuration();
c.TargetDatabase = new DbConnectionInfo(cs, "System.Data.SqlClient");
var migrator = new DbMigrator(c);
Log($"{migrator.GetPendingMigrations().Count()} pending migrations");
migrator.Update();
Log("Complete");
}
catch (Exception e)
{
Log($"Failed: {e.GetType().FullName} {e.Message}");
throw;
}
}
Then I generated a custom deployment script: https://github.com/projectkudu/kudu/wiki/Custom-Deployment-Script
In that script, I call my migrate.exe which runs the migrations. Has been working quite well.
I am using EF6 Code First with migrations in a new project. I have used this in a few projects already without issue.
Now this new project is against an existing database.
I generated the standard Initial migration file, then deleted all the contents leaving just the Up() and Down() methods. This has worked for me in other projects, but not this time.
When I run update-database from the Package Manager Console, all works as expected.
PM> update-database
Specify the '-Verbose' flag to view the SQL statements being applied to the target database.
No pending explicit migrations.
Running Seed method.
Then I execute the migrations from code (as needed in production) and I get...
Unable to update database to match the current model because there are pending changes and automatic migration is disabled. Either write the pending model changes to a code-based migration or enable automatic migration. Set DbMigrationsConfiguration.AutomaticMigrationsEnabled to true to enable automatic migration.
I have been trying to get my head around this one for two days, and not getting anywhere.
I have even added another migration file called "stub" and it is generated blank. EF does not see any changes to my model (of which there are none), so it has nothing to generate. Yet the migration execution via code persists with the error that there are migrations pending.
I have attached a logger to the code execution of the migrations and the output is this.
Target database is: 'FMS' (DataSource: (local)\SQL2012, Provider: System.Data.SqlClient, Origin: Configuration).
No pending explicit migrations.
And then I get the error message in my browser.
My configuration class
namespace FMS.Infrastructure.Repository.EF.Migrations.Stage
{
public sealed class StageConfiguration : DbMigrationsConfiguration<StageDb>
{
public StageConfiguration()
{
AutomaticMigrationsEnabled = false;
MigrationsDirectory = #"Migrations\Stage";
CommandTimeout = 3000;
ContextKey = "FMS.Stage";
}
}
}
And the code that performs the migrations
Database.SetInitializer(new MigrateDatabaseToLatestVersion<StageDb, StageConfiguration>());
var dbMigrator = new DbMigrator(new StageConfiguration());
var logger = new MigratorLoggingDecorator(dbMigrator, new DbMigrationLogger());
foreach (string migration in dbMigrator.GetPendingMigrations())
Console.WriteLine(migration);
logger.Update();
I hope this is clear enough for those willing to try assist. If anyone has a tip, I am all ears. This is making me grey.
I am running Entity Framework with Code First Migrations. My new release adds a table, modifies a few tables, and run some scripts. This works perfectly when developing locally using update-database.
Upon deployment the new table was not created and I was receiving errors from my client. I attached the debugger to the deployed site to track through what was happening. It reached the controller, went through the normal flow, and upon hitting the first database call to the new (but not actually existing yet) table it hopped into the Configuration class for my migration.
internal sealed class Configuration : DbMigrationsConfiguration<myProject.api.AuthContext>
{
public Configuration()
{
AutomaticMigrationsEnabled = false;
MigrationsDirectory = #"Migrations\Auth";
ContextKey = "myProject.api.AuthContext";
}
So I'm thinking great, all should be well. It goes through all of these, returns to the initial database call, but then that call returns an error, pasted below
The model backing the 'AuthContext' 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 is surprising since indeed I have enabled code first migrations! Using the standard enable-migrations and add-migration, which work perfectly on my local machine when I issue the update-database command.
1) How can I get my Code First migrations to run once deployed to Azure?
Update 1
Here are my publish settings. For some reason I do not have the checkbox option for: "Execute Code First Migrations" and am guessing that's the issue...
Huzzah! My update was the issue. I found from other SO posts that his happens sometimes. A Clean and Rebuild, followed by restarting VS, restored the 'Execute Code First Migrations' checkbox. Re-deployed and everything worked perfectly.
Have you checked these lines of code?
In your web.config:
<appSettings>
<add key="MigrateDatabaseToLatestVersion" value="true"/>
</appSettings>
In your global.asax.cs / Startup.cs (OWIN startup):
var configuration = new Migrations.Configuration();
var migrator = new DbMigrator(configuration);
migrator.Update();
Entity Framework 6.0.2. .Net 4. I am trying to update SQL Server CE 4.0 database from code, so when a new version of the application is released, the database(s) are automatically upgraded.
There are two data contexts in the project and they are targeting two different databases. This is what I am doing to update one of them:
Private Sub UpdateDatabase(connectionString As String)
Dim config As DbMigrationsConfiguration(Of MainDBContext) = New DbMigrationsConfiguration(Of MainDBContext)()
config.TargetDatabase = New System.Data.Entity.Infrastructure.DbConnectionInfo(connectionString, "System.Data.SqlServerCe.4.0")
config.ContextKey = "MyProject.MainDBContext"
Dim migrator As DbMigrator = New DbMigrator(config)
migrator.Update()
End Sub
The message from the Update method is that there are pending changes so I have to either run Add-Migration or enable Automatic Migrations. However, Add-Migration has been run and when I do allow automatic migrations, Update tries to create tables which already are in the DB.
Running Update-Database works fine when called like this:
Update-Database -configuration MyProject.MigrationsMainDb.Configuration -Verbose
I checked that the connection string used in the UpdateDatabase function is same as the one in the config file (used by Update-Database). I also tried not setting the ContextKey property, but it made no difference.
Is there anything obvious that I am doing wrong? Why does the migrator thinks there are pending updates but Update-Database is fine...?
I made it working. I realized that instead of creating the "generic" configuration class I should create the configuration class which had been added to the project by Enable-Migrations command. So the code has been changed to the following:
Private Sub UpdateDatabase(connectionString As String)
Dim config As MigrationsMainDb.Configuration = New MigrationsMainDb.Configuration()
config.TargetDatabase = New System.Data.Entity.Infrastructure.DbConnectionInfo(connectionString, "System.Data.SqlServerCe.4.0")
Dim migrator As DbMigrator = New DbMigrator(config)
migrator.Update()
End Sub
And this change resulted in the configuration object having properties set up correctly. For example the MigrationsDirectory property, which was not set before to what it should be. This was probably the reason of the issue - the migrator not finding migrations (looking for them in wrong directory) and assuming that the whole model has to be applied to the DB.
After making this change, I still had a small glitch with a pending change. In Visual Studio a file looked like modified, with one extra (test) property in the class, but when I tried to remove the extra line, I got a message from VS like "edited on master", or something like that. I closed the file and reopened - the extra property disappeared. I guess it was something with git, checking out branches and VS not refreshing files properly? Not sure really. But once this line was no longer there and the modified code in place, the Update function started working fine.
Update now updates existing databases and successfully creates new ones. Great :)
I would like to introduce Code First Migrations to my project, but I am unsure of how to handle deploying this to my client for testing. Until now, things have been quite simple, and I have just used a CreateDatabaseIfNotExists initializer. Now, I have two scenarios:
He deletes his existing, before-migrations, database, and uses an initializer to create a new, with-migrations, database, and we use migrations from here on to upgrade his database. Can I use the MigrateDatabaseToLatestVersion initializer to create the DB if missing as well?
I just deploy my code and let it perform migrations. I'm not quite sure if anything but using a MigrateDatabaseToLatestVersion is required here. Will this upgrade a pre-migrations database to one suitable for migrations?
This is what I do when automatic migration is required; I hope this helps you find a solution:
Database.SetInitializer(
new MigrateDatabaseToLatestVersion<ContextFileName, PathToMigrationsConfig>()
);
Database.Initialize(false);
In the configuration file for the migrations, I set the following in the constructor
AutomaticMigrationsEnabled = true;
AutomaticMigrationDataLossAllowed = false;
In the configuration file you should have an override of the seed method, if not you can add it and fill in your seed data.
What the above will do is create/upgrade the database to the latest as long as no data loss occurs. This should allow you hand off the code to the client.
On a side note, for a production system I will usually argue the point of not doing this. This had many disadvantages. For databases I do not have control over I have yet to find a client that has refused the generated script file.
You can get this by using the following command after you add a migration through the Package Manager Console:
Update-database –script -verbose