【问题标题】:Unable to generate an explicit migration in entity framework无法在实体框架中生成显式迁移
【发布时间】:2012-04-06 18:04:54
【问题描述】:

我正在添加新的迁移,但此消息显示:

无法生成显式迁移,因为以下原因 显式迁移待定:[201203170856167_left]。应用 在尝试生成新迁移之前等待显式迁移 显式迁移。

谁能帮帮我?

【问题讨论】:

  • 这发生在我身上,当时我不小心将我的启动项目切换到了另一个项目。您(或阅读本文的其他人)可能希望在尝试更深入的故障排除之前快速检查一下(尤其是那些您必须开始删除迁移等的故障)。
  • Migrations 目录中有一个迁移类,在数据库的_MigrationHistory 中没有更新。删除该类以在迁移目录和数据库中具有相同的状态解决了我的问题。
  • 这随机发生在我身上。当它发生时,它表明我所有的迁移都需要应用。我必须重新启动 Visual Studio 才能让它工作,因为我已经正确设置了所有内容。

标签: entity-framework entity-framework-migrations


【解决方案1】:

它告诉您在您的应用程序中有一些未处理的迁移,它需要运行Update-Database 才能添加另一个迁移。

【讨论】:

  • 我想重新创建一个初始迁移?这会阻止您这样做吗?
  • 对我不起作用,Update-Database 只是给了我另一个错误。我必须先删除待处理的文件。
  • Thomas 的回答对我的类似案例很有用。
  • 可能需要声明一个启动项目-StartupProject ContentHub.Database
  • Update-Database 给出 >无法更新数据库以匹配当前模型,因为有待处理的更改
【解决方案2】:

您需要从包管理器控制台运行“update-database”以将更改推送到数据库,或者您可以从 Migrations 文件夹中删除待处理的迁移文件 ([201203170856167_left]),然后重新运行“add-迁移”以根据您的编辑创建一个全新的迁移。

【讨论】:

  • 我删除了迁移文件并运行了 add-migration,但仍然报同样的错误。
  • 谢谢,关于删除待处理迁移文件的提示是救命稻草
【解决方案3】:

如果您还没有使用过Update-Database,您可以将其删除。如果您已运行更新,请使用 Update-Database -TargetMigration "NameOfPreviousMigration" 回滚,然后将其删除。

参考: http://elegantcode.com/2012/04/12/entity-framework-migrations-tips/

我直接从这里复制了这段文字:How do I undo the last Add-Migration command?

【讨论】:

    【解决方案4】:

    我遇到了同样的问题。显然,实体框架在无法连接到数据库时会生成此错误。因此,在搜索其他问题之前,请确保您能够访问它。

    【讨论】:

    • 我还要补充一点,当您将 App.config 移动到另一个项目时,或者如果它在您的项目中完全丢失,或者如果它在您的项目中但配置不正确,就会出现这种情况。
    • 我的 IP 更改后出现了同样的错误(切换位置后和 dyn dns 更改后都发生了)。这导致了我们用来撤销登录的 Azure 数据库中的防火墙。无用的 EF 迁移给出了上述错误,而不是“无法登录”...
    • 我想说的另一点是确保检查您的启动项目是否与您的数据库上下文的连接字符串有关。当我临时更改了我的启动项目并且没有意识到另一个项目没有相同的连接字符串时,我遇到了这个问题。
    • 添加到@GageTrader:我有多个启动项目,一个没有配置,还有一个带有 EF-config 的 Web 项目。具有迁移的(存储库)项目在其 app.config 中具有与 Web 项目相同的 EF 配置。但是即使我选择了存储库项目作为启动项目它也没有工作,但是当我将网络项目设置为启动它时。
    • 我必须明确声明 -ConnectionString 参数,这对我有用
    【解决方案5】:

    此错误也可能意味着迁移不再被识别。这发生在我更改了 Migrations.Configuration 中的 ContextKey 的值之后。 解决方案是简单地更新数据库表“__MigrationHistory”中的 ContextKey(或者恢复我猜的 Configuration 类中的值)。应用程序中的 ContextKey 和 Namespace 应该匹配。

    【讨论】:

    • 这对我来说是正确的答案。当我将一个旧项目用于一个新的类似项目时,我无法通过旧迁移对数据库进行更改。正如 Thomas 所建议的,Migrations 中的命名空间与 _MigrationsHistory 表中的 Contextkey 不同,这导致无法识别旧的迁移。
    • 这对我有帮助,因为我通过重命名解决方案引起了问题。在此过程中,我重命名了 ContextKey,因此它不再匹配 _MigrationHistory 条目。
    • 也为我工作,在配置中设置一个明确的上下文键,在 __MigrationHistory 中更改它,更新数据库决定一切都很酷。谢谢!
    • 荒谬,但它是正确的。如果您更新了项目名称,或者如果您将项目(我的情况)拆分为几个项目并且您尝试将新项目从新项目添加到同一个数据库,则必须使用正确的 ContextKey,您可以在配置构造函数中设置它(您必须使用目标数据库中的 __MigrationHistory 表中的 Context 键)
    • 这里相同,我重命名了我的默认命名空间并在我的解决方案中替换了它,这导致了这个问题
    【解决方案6】:

    遇到此问题时,请尝试将参数添加到您的 add-migration cmdlet。例如,指定启动项目以及连接字符串名称可以帮助 EF 找到您的目标数据库。

    add-migration Delta_Defect_0973 -ConfigurationTypeName your.namespace.ContextClassName -StartUpProject DeltaProject -ConnectionStringName DeltaSQL
    

    地点:

    Delta_Defect_0973 是您的迁移名称

    your.namespace.ContextClassName 是迁移文件夹中配置类的名称,以全名空间为前缀。

    DeltaProject 是带有 web.config 或 app.config 文件的主项目的名称。

    DeltaSQL 是在 web.config 或 app.config 文件中定义的连接字符串的名称。

    【讨论】:

    • 谢谢。这对我很有帮助。
    • 另外,如果您在解决方案中使用依赖注入,您可能必须在包管理器控制台中选择不同的默认项目。如果 EF 无法找到您的迁移,请尝试选择实际包含迁移的项目作为默认项目。
    【解决方案7】:

    1。连接字符串/连接权限

    再次检查连接字符串。

    确保与您连接的用户仍然有权读取[__MigrationHistory] 并有权编辑架构。

    您也可以尝试更改应用程序或 Web 配置文件中的连接字符串,以使用 Integrated Security (Windows Auth) 以 yourself 身份运行 add-migration 命令.

    例如:

    connectionString="data source=server;initial catalog=db;persist security info=True;Integrated Security=SSPI;" 
    

    此连接字符串将放入 DbContext 所在项目的 App.config 文件中。

    2。启动项目

    您可以在命令行中指定启动项目,也可以右键单击包含DbContextConfiguration 和迁移文件夹的项目,然后选择设置为启动项目。我是认真的,这实际上可以提供帮助。

    【讨论】:

    • 哈哈。我希望这会得到更多的支持。这种情况经常发生在我身上,Integrated Security 修复效果很好!
    • 我遇到了同样的问题,迁移命令都不起作用。原来没有设置启动项目是罪魁祸首。设置解决了我的问题。
    • 更改启动项目对我有用!我确信它不会起作用,但我还是尝试了它,因为其他一切都失败了。很好的答案。
    • “设置为启动” - 从来没有会猜到!谢谢!!
    • 是的,我故意更改了启动项目,忘记改回来了。有趣的是,之前的一次迁移是通过适当的启动项目完成的,所以一切正常。但这现在是合乎逻辑的 - b/c EF 从项目中获取连接字符串,因此它“不知道”迁移实际上已经应用于 DB...
    【解决方案8】:

    场景

    • 我在一个创建新数据库迁移的分支中工作。
    • 我已准备好从 master 更新,但 master 最近也进行了数据库迁移。
    • 我删除了我分支的数据库迁移以防止冲突。
    • 我“从主人那里更新”。

    问题

    从 master 更新后,我运行“Add-Migration my_migration_name”,但收到以下错误:

    无法生成显式迁移,因为以下原因 显式迁移待定: [201607181944091_AddExternalEmailActivity]。应用待处理的显式 在尝试生成新的显式迁移之前迁移。

    所以,我运行“更新数据库”并得到以下错误:

    无法更新数据库以匹配当前模型,因为有 挂起的更改和自动迁移已禁用

    解决方案

    此时重新运行“Add-Migration my_migration_name”解决了我的问题。我的理论是,运行“Update-Database”会使所有内容都处于“Add-Migration”工作所需的状态。

    【讨论】:

      【解决方案9】:

      此错误意味着在执行另一个显式迁移之前需要提交待处理的迁移。你可以选择

      1. 使用 Update-Database 命令执行那些挂起的迁移
      2. 删除那些挂起的迁移。最安全的方法是打开 Migrations 文件夹,右键单击 [201203170856167_left] > 从项目中排除

      在此之后,您可以再次开始“添加迁移...”

      希望对你有帮助

      【讨论】:

        【解决方案10】:

        我也遇到过这个问题。它是在我创建新数据库时出现的,并且我的代码优先数据库迁移有待更改,然后我尝试运行“更新数据库”命令。解决方案:运行“Add-Migration -MigrationName”命令为新数据库创建新迁移。然后运行“更新数据库”命令。

        【讨论】:

          【解决方案11】:

          我遇到了同样的问题,只能通过运行 Add-Migration 'MigrationName' -Force 解决它

          -Force 是重要的部分。

          【讨论】:

            【解决方案12】:

            对于我知道在运行 Add-Migration 时是最新的数据库,我也遇到了这个问题。只需再次运行 Add-Migration 命令即可解决。怀疑存在连接问题,正如上面 Robin Dorbell 所建议的那样。

            【讨论】:

            • 在我的场景中运行命令时数据库名称区分大小写。只要使连接字符串与数据库中的内容完全相同,它就可以正常工作
            【解决方案13】:

            遇到了同样的问题,并且能够通过上述答案的一些提示来解决:

            • 在包管理器控制台中检查默认项目(指向具有迁移配置的项目
            • 确保启动项目的 web.config 具有有效的连接字符串 ( 或
            • 确保带有迁移的项目有一个 app.config / web.config 和一个有效的连接字符串
            • 检查数据库中的权限(对于您在连接字符串中配置的用户)

            在包管理器控制台中使用“update-database -verbose”来获取迁移尝试连接的更具体的信息。 (帮助我发现我的启动项目设置不正确......)

            【讨论】:

            • 跑了“update-database -verbose”,发现我的连接字符串坏了,哈哈。所以 add-migration 命令给出了错误的信息。
            • “确保启动项目{...}”解决了我的问题。谢谢@flex
            【解决方案14】:

            只要我的两分钱:

            我的场景:

            1. 我将本地数据库恢复到工作状态。
            2. 已经应用了迁移。
            3. 每当我尝试添加新迁移时,我都会收到关于待处理迁移的错误,正如我的 OP 中提到的那样。

            解决方案:

            为了解决这个问题,我只是提供了更明确的参数:

            Add-Migration -ConnectionString "Server=localhost\SQLEXPRESS;Database=YourDataBase;Trusted_Connection=True;" -ConnectionProviderName "System.Data.SqlClient" -verbose
            

            我相信您可以在 app.config 文件夹中设置一个设置,以允许您默认此行​​为,这样您就不必每次都提供显式参数。但是我不确定如何执行此操作。

            【讨论】:

            • 这对我有用,我只是在上面显示的命令末尾添加了迁移的名称。
            • = ) - 很高兴我能帮上忙。
            • -ConnectionStringName 是一个替代方案,它将按名称从您的配置中提取连接字符串
            • 这对我有帮助,因为我没有将连接字符串存储在配置文件中
            【解决方案15】:

            当我突然重命名数据库中已经存在的旧迁移类时发生了这种情况。我检查了 VCS 历史记录,确定并重新命名。之后所有的工作。

            【讨论】:

              【解决方案16】:

              我的本​​地数据库没有填充或不存在 __MigrationHistory。我手动创建了表,然后将该表中的数据从 PROD 迁移到我的本地数据库。这导致 VS 认为迁移已被应用(确实如此)。

              【讨论】:

              • 我遇到了同样的问题,我将实时数据库合并到生产环境中,但迁移历史记录丢失了。
              【解决方案17】:

              在从迁移恢复到另一个迁移后,我遇到了完全相同的问题。

              在我的例子中,我从“migration06”“targetedmigration”到“migration04”。

              我需要删除“migration0”6,然后才能强制创建“migration05”。这基本上意味着您只需在目标迁移之后保持下一次迁移。

              【讨论】:

                【解决方案18】:

                提示:如果您不确定,最好将-Script 开关用于迁移命令。它还真的有助于理解 Update-Database 的实际作用。

                我运行以下命令来更新数据库,然后我得到一个可以手动应用的脚本(或者在没有 -Script 标签的情况下再次运行它)。

                对于Update-Database,我将运行以下命令:

                Update-Database -Script -ConfigurationTypeName Configuration_ASPNETIdentity -ConnectionStringName SQL_AzureLive

                SQL_AzureLive 是我的配置中命名的连接字符串。

                然后我可以验证 SQL 看起来是否正确,应用它并完成。正如许多其他人所说,如果连接字符串错误或无效,您将收到此错误。

                【讨论】:

                  【解决方案19】:

                  存在歧义,因此存在错误。最好的方法是排除当前的迁移文件并创建新的迁移(add-migration)文件,然后将新迁移的内容复制到排除的文件并再次包含它并运行update-database 命令。

                  【讨论】:

                  • 我刚刚运行了update-database 命令,然后重试了我的add-migration 命令,它成功了
                  【解决方案20】:

                  我做了另一种方式。 我完全删除了数据库并在 vs. 中再次运行“update-database”。

                  【讨论】:

                  • 这不提供可行的修复;有效迁移保留现有结构。
                  【解决方案21】:

                  我有一个更简单的问题。当我与工作站上连接的客户端站点建立 VPN 连接时,VS 错误地报告了此错误。问题是 DBMS 安全设置为仅接受来自我的真实本地 IP 的请求。只需关闭 VPN 即可解决问题。

                  【讨论】:

                    【解决方案22】:

                    我解决了同样的问题:

                    • 删除旧的迁移文件
                    • 更新数据库-force
                    • 添加迁移添加实体
                    • 更新数据库

                    【讨论】:

                      【解决方案23】:

                      就我而言(使用 MS Visual Studio),就像重启 Visual Studio 一样简单。

                      【讨论】:

                        【解决方案24】:

                        对我来说,我从Migrations 文件夹中删除了迁移文件(在您的情况下为“201203170856167_left”),然后在包管理器控制台中运行以下命令

                        Add-Migration <Parameter>
                        Update-Database
                        

                        【讨论】:

                          【解决方案25】:

                          在我的情况下,我忘记在 Azure 的防火墙规则中添加我的 IP 地址,基本上是因为我无法连接到数据库,所以我收到了这个错误。因此,特别针对我的情况,我在 Azure 的数据库防火墙规则中添加了我的 IP 地址,并且一切正常。 除此之外,可能是代理/互联网连接/数据库用户名密码/数据库连接字符串等问题。或者显然,您可能需要运行 Update-Database 命令的待处理迁移。

                          【讨论】:

                            【解决方案26】:

                            从历史上看,我总是通过删除待处理的迁移来解决这个问题,或者如果只剩下 1 个并且这是最理想的,则使用 -f 重新创建它。

                            最近,这对我不起作用。

                            第一次发生这种情况时,我重新启动了 Visual Studio,然后它让我继续。

                            第二次,它仅在我对项目运行 Clean 后才起作用。尽管从资源管理器中删除了所有文件,但几乎就像保留了挂起的迁移一样。

                            【讨论】:

                              【解决方案27】:

                              这不是很多人的答案,但是当 EF 无法连接到数据库时,它会抛出这个错误。如果您像我一样在家工作,请确保您仍然连接到您的 VPN!

                              【讨论】:

                                【解决方案28】:

                                旧帖子,但可能对某人有所帮助。 对我来说,这是因为我重命名了项目的 Assembly nameDefault namespace。 所以我不得不将_MigrationHisotry 表中的ContextKey 更新为Assembly nameDefault namespace 的新值。老实说我不知道​​应该使用哪一个,因为对我来说两者都是一样的!

                                【讨论】:

                                  【解决方案29】:

                                  就我而言,只是将启动项目更改为包含我的迁移文件夹的项目,还要确保您在包控制台管理器中选择了相同的项目。

                                  【讨论】:

                                    猜你喜欢
                                    • 2015-01-01
                                    • 2017-09-20
                                    • 2016-09-15
                                    • 1970-01-01
                                    • 1970-01-01
                                    • 2020-10-23
                                    • 1970-01-01
                                    • 2015-05-11
                                    相关资源
                                    最近更新 更多