Entity Framework migration and product versioning

c# entity-framework entity-framework-6



I'm using EF6 with one of our software product (network base web application) and we've different versions of products installed on customer machines. All customers have support period of x months so they are running on different versions of product and their respective databases are on different EF migrations.

I have a few other colleagues helping me with support of the product and they regularly deal with support phone calls from customer for different versions of product.


Product only supports upgrading EF database and downgrading is not supported due to data loss concerns. So when we need to support an older version we use an internal tool to up/down-grade EF database. Problem is my colleagues are not aware about which database migration goes with what version of our product.

So my question: is there a way to attach our product version to migration history row?

What I've considered so far:

  1. Embed product version in the name of the migration.

    This is doable but I need to train other devs to make sure to include product version in the migration.

  2. Create an empty migration with each major release of the product.

    This one has the same issue as approach 1. I can automate this into the product release script but that involves too much effort and not to mention possible issues.

What I want:

I'm planing to attach product version with migration itself. Meaning, I want to add a new column to the MigrationHistory table which will hold this information (will be deriving my new class from HistoryRow).

What I'm not sure about is, how to intercept database migration template so that I can embed product version (assembly version) to the migration and I don't have to remember to do it manually.

I'm sure one of you must have feel this pain and possibly there is a better solution out there. Any ideas/suggestions?

8/18/2018 6:24:10 AM

Popular Answer

You can customize the Migrations History table by implementing and registering a custom subclass of HistoryContext. Then you have all the interception methods for a normal DbContext: SaveChanges, ValidateEntity, etc.

But I don't think this really helps. You don't actually care when the Migration is applied, which is what the HistoryContext will tell you. You care when the Migration was created relative to your releases.

There is, in fact, nothing in your source that will tell you this. You can't know what release a change will end up in when you make it.

I think your idea to "Create an empty migration with each major release of the product." is the right one. In that empty migration you can add code to update some table that stores the name of the release.

8/18/2018 1:07:11 PM

Related Questions


Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow