Code First Migration with Connection Strings

Why does Entity Framework's EF Migrations Add-Migration step require a database connection string?

Has a solution which i consider less labor intensive in the long run. As if you create a connection string with the same name

On your context :base("DBName")

Connection string name and initial catalog match the DBName you specified and you don't need to enter the connection string name every time.

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.