【问题标题】:Entity Framework migrations stopped detecting the POCO updates实体框架迁移停止检测 POCO 更新
【发布时间】:2012-01-19 09:35:33
【问题描述】:

我正在使用实体框架和实体框架迁移来实现使用代码优先和自动迁移的解决方案。

它曾经运行良好,但突然停止检测我对 POCO 所做的更新。现在,当我添加一个新属性(非常简单的属性,如年龄或电子邮件)并执行 Update-Database 时,什么也没有发生,它给了我这个:

指定“-Verbose”标志以查看迁移期间正在执行的 SQL 命令。
找到 0 个待处理的显式迁移:[]。
添加种子数据(如果在迁移设置类中重写了种子方法)。

没有任何更新!

有人知道为什么会这样吗?

【问题讨论】:

  • AutomaticMigrationsEnabled 标志是否仍设置?
  • 是的,我也遇到了一些问题,我也不得不重新安装它,我想知道是不是因为我使用了新的 NuGet 1.6 方法,不在源代码管理中存储包。
  • 但这是我通过解决方法修复它的方法 我卸载了迁移包并再次安装它,然后 update-database ,它修复了它
  • @Betty 我所说的是一种解决方法而不是解决方案,我宁愿不批准这个作为答案,我有最新的 NuGet 补丁,但我仍然不时遇到这个问题。跨度>
  • 我也遇到了同样的问题,但模型优先。修改了我的模型,但没有更新到数据库...现在提到,我是我团队中唯一使用 NuGet 的人...会回复您

标签: entity-framework migration ef-code-first entity-framework-migrations


【解决方案1】:

这可能有两个原因:

  1. 代码中还有其他一些 DbContext,这就是自动迁移无法决定使用哪个上下文的原因。
  2. 有一些新变化,循环比较架构和代码模型,所以 EF 根本找不到差异。

一般来说,自动迁移实现起来既简单又快速,但使用它们并不安全。在某些阶段,此类迁移可能会失败。

几年前,我开发了基于 Linq2SQL 的微型 ORM,AcroDB Library,它使用了 SubSonic 的自动迁移。几乎与现在可以执行的 EF 迁移相同。它非常适合小型项目和需要处理或更改的少量数据,但是当项目增长到 15 个以上的表时,它就变成了一场噩梦。这就是 MS 最近宣布 Code-driven migrations 的原因。它们更安全,更适合项目。另外,你可以看看Migrator.Net(这时候比EF好一点)。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2012-03-22
    • 1970-01-01
    • 1970-01-01
    • 2011-08-11
    • 2015-05-11
    • 1970-01-01
    相关资源
    最近更新 更多