Code First Migration with Connection Strings

Question

So I've managed to get Code First running and it works great.

Since I am still developing the application the structure of the Database isn't finalize and so I need to implement migrations.

I followed the Official Blog Post and got that Update-Database command working.

However, this only updates the SQLExpress version of the database. The production version of the database is on Azure and I specify the connection string at run time so the Update-Database command doesn't work on that.

So my final question is: how do I apply automatic migrations to the production database whose connection string is specified at runtime?

question from:https://stackoverflow.com/questions/9441530/code-first-migration-with-connection-strings

Answer 1

On the package manager console type:

Get-Help Update-Database

Relevant part:

    Update-Database [-SourceMigration <String>] [-TargetMigration <String>] [-Script] [-Force] [-ProjectName <String>] [-StartUpProjectName <String>] [-ConfigurationTypeName <String>] [-ConnectionStringName <String>] [<Com
monParameters>]

So you can do a Update-Database -ConnectionStringName "MyConnectionString" and it should work like a charm.

You also have a MigrateDatabaseToLatestVersion database initializer, if you set it (via Database.SetInitializer()), when you deploy your app on production with proper connection string, on first db access it should automagically migrate your db to the latest version.

I suggest caution though, always backup things.

Update

@Alexy Strakh recent comments spawned another argument worth putting in the answer.

Properly configuring a deployment system using Code First Migrations, given 2 ConnectionStrings.

1. Define your connection strings in web.config (prod and dev), with default passwords
2. Have the configuration system of your application know about the prod and dev connection configurations, optionally build unit tests to ensure the right one is picked*
3. Employ config file transformation and have it transform your web.config into the one with production values
4. Deploy your package to production (this should be the most cutting edge way)

You are not supposed to interact with the production environment from your development box, but if you really need to do that, then make it a temporary solution that needs to be reverted as soon as you're done.

Another option is to simply use the Web.Debug.config and Web.Release.config and have a central template for the main web.config (which would be the only one you check in in your source control).

Just make sure never to check in production or personal-development passwords (if any).

*You can use the DEBUG symbol to check how the application is running.