Home/ Questions/Q 7600007
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-30T22:48:19+00:00

During development, I like the idea of frameworks like Entity Framework 4.3 Migrations (although

  • 0

During development, I like the idea of frameworks like Entity Framework 4.3 Migrations (although I need it to work with sql scripts instead of Migration classes) keeping all developer databases up-to-date. Someone does an update to get the latest source, they try to run the application and get an error that they need to update their database to the latest migration (or have the migration happen automatically). Migration files are timestamped so devs don’t have to worry about naming two files the same or the sequence the files need to be executed in.

When I get ready to build a WebDeploy deployment package, I want the package to contain the scripts required to move the production database to the latest db version. So somehow, MSBuild or WebDeploy need to make a decision about which scripts must be packaged. For deployment I don’t want the application to try to update itself like what EF offers. I want to either hand the package to the IT department or do an auto-deploy through a deployment server.

Some of my questions are:

  1. Can EF 4.3 work with sql scripts instead of DBMigration classes for my development needs (I’m already using it for my ORM so it would be nice if it could)?

  2. Does MSBuild or WebDeploy understand the concept of database migrations (e.g. does it recognize the EF. 4.3 migrationHistory table) or do I have to make sure to give it just the scripts it needs to run that will bring my prod db to the latest migration? Manually deciding which scripts should be pakaged is not something I want to do so is there a MS WebDeploy extension that understands migrations?

  3. Are my concerns and ideas valid? I’m just researching this stuff so I don’t really know.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I think that your concerns are valid. During development anything that keeps the developer machines in sync will do. When deploying, more control is needed.

    In my project we’ve decided to only use code-based migrations, to ensure that all databases are migrated in the same order with the same steps. Automatic migration and db creation is disabled by a custom initialization strategy that only checks that the db exists and is valid.

    I’ve written more about the details in Prevent EF Migrations from Creating or Changing the Database. I’ve also looked a bit into merge conflicts which will eventually happen with multiple developers.

    • 0