场景：
我将EF6与我们的一种软件产品（基于网络的Web应用程序）一起使用，并且在客户计算机上安装了不同版本的产品。所有客户的支持期均为x个月，因此他们在不同版本的产品上运行，并且各自的数据库在不同的EF迁移上。
我还有其他一些同事在为我提供产品支持，他们会定期处理客户针对不同版本产品的支持电话。
问题：
产品仅支持升级EF数据库，并且由于数据丢失的考虑，不支持降级。因此，当我们需要支持旧版本时，我们使用内部工具来升级/降级EF数据库。问题是我的同事们不知道哪个数据库迁移与我们产品的哪个版本一起进行。
所以我的问题是：是否可以将我们的产品版本附加到迁移历史记录行上？
到目前为止我所考虑的：
以迁移名称的形式嵌入产品版本。
这是可行的，但我需要培训其他开发人员以确保在迁移中包括产品版本。
在产品的每个主要版本中创建一个空迁移。
这个问题与方法1相同。我可以将其自动化到产品发布脚本中，但这需要太多的努力，更不用说可能的问题了。
我想要的：
我打算将产品版本附加到迁移本身。意思是，我想在MigrationHistory表中添加一个新列，其中将保存此信息（将从HistoryRow派生我的新类）。
我不确定的是，如何拦截数据库迁移模板，以便可以将产品版本（组装版本）嵌入到迁移中，而不必记得手动进行。
我敢肯定，你们当中的某人一定已经感受到了这种痛苦，并且可能有更好的解决方案。有任何想法/建议吗？
答案 0 :(得分：0)
您可以通过实现和注册customize the Migrations History table的自定义子类来HistoryContext。然后，您拥有了普通DbContext的所有拦截方法：SaveChanges，ValidateEntity等。
但是我认为这没有帮助。您实际上并不在乎何时应用迁移，这是HistoryContext会告诉您的。相对于您的发行版创建时，您会很在意。
实际上，您的消息来源中没有任何内容可以告诉您这一点。您不知道更改后最终会发布到哪个版本。
我认为您的想法是“在产品的每个主要版本中创建一个空的迁移”。是正确的。在空迁移中，您可以添加代码以更新一些存储版本名称的表。