我在使用SQL Azure数据库的应用程序中使用EF迁移。它工作正常，直到我手动删除SQL Azure中的表。现在，当我发布我的应用程序时，删除表不是在SQL Azure中创建的。这是我得到的错误。未使用EF迁移创建SQL Azure表
Cannot find the object "dbo.TableName" because it does not exist
or you do not have permissions.
我觉得我创建了数据库和我的模型之间的一些不一致。
我正在使用自动迁移。
为什么你删除表格开始？你想让它重新创建吗？
在我们进入棘手的解决方案之前，您是否尝试过使用-TargetMigration选项在您的表创建之前回滚到迁移？我有一种感觉，你会得到关于试图删除不存在的fk表或索引的SQL错误，但它值得一试。您可以使用此命令update-database -TargetMigration YourOldMigration来完成此操作。这将通过运行迁移文件的Down（）方法中找到的命令来回滚在目标迁移后应用的所有迁移。如果您遇到SQL错误，您可以尝试修改Down（）方法的内容以避免错误。小心。这可能会导致数据丢失。如果EF警告你这个，你不在乎。尝试添加-Force以结束您的命令。
或者和另外....
您的迁移不只是你的数据库方案比较，你的DbContext /模型计算。如果你在sql server management studio中打开你的sql azure数据库，你应该会看到一个名为__MigrationHistory的表。它通过自动迁移来存储已应用到数据库的所有迁移。
开始前请仔细阅读。有些因素在跳入之前需要考虑。假设您尚未操作它，则应该能够为最初创建表的变更集找到一行。删除该行。现在，EF自动迁移将认为该变更尚未应用于您的数据库。如果你运行update-database，它应该尝试并重新运行它。
如果您在该迁移文件中有其他更改，它将尝试并重新运行这些更改。这可能会导致各种SQL错误。您可能需要手动回滚也是该迁移一部分的所有更改。担心数据丢失？尝试将数据复制到手动创建的表中进行存储，直到完成后。在迁移到工作之后，您可以将数据复制回新的表格/列。
双重选择。如果您没有太多的开发工作，并且您对数据丢失没有太多担忧，那么删除整个数据库并让自动迁移从头开始重新创建它可能会更容易。
希望能让你在那里