如何在不使用迁移的情况下自定义内置 AspNet 身份答案

【问题标题】：How to customize built-in AspNet identity without using migration如何在不使用迁移的情况下自定义内置 AspNet 身份
【发布时间】：2016-05-31 08:34:51
【问题描述】：

我在 Visual Studio 2015（社区版）中创建了新的 Web 项目并选择了个人身份。我已按照说明使用 EF 迁移在自定义用户属性上同步代码和数据库，并且效果很好。

但是，如果我不想使用数据库迁移，如何添加自定义用户属性？我在 ApplicationUser 和 DB 表字段中手动添加了 C# 属性，但总是得到“自创建数据库以来，支持 xxxxxContext 的模型已更改......”错误。我应该在 OnModelCreating() 覆盖中添加这些表映射吗？

对于那些对 EF 迁移感到满意的人，这将如何在部署到不同环境中发挥作用？

【问题讨论】：

好吧，如果你要改变你的模型，你需要一种方法来让它们进入其他环境。在早期开发期间，您可以只使用像 DropCreateDatabase 这样的初始化程序来将您的更改放入数据库中。一旦你有了你关心的数据，你就需要迁移。您可以生成一个 SQL 脚本来更新其他环境中的架构。
我刚刚发现（感谢其他 SO 帖子）删除/重命名 __MigrationHistory 表并调用 Database.SetInitializer(null) 将禁用此迁移功能。迁移适用于小型/POC 项目，但对于实际应用程序，单独的数据库项目在跟踪更改和部署管理方面要好得多。
嗯，我们已经在 2 年多的时间里使用迁移来进行大规模的“真实”应用程序，现在有 4 个不同的环境（DEV、QA、TRAIN、PROD）。一旦你理解了问题，它就可以正常工作。
问题是对数据库模式没有更改跟踪 - 表、索引、为什么和谁。您唯一拥有的是 _MigrationHistory 表。对于复杂的 LOB 应用程序，这是不可取的。
我们从迁移和源代码控制中得到我们需要的东西，但同意它并不适用于所有情况。

标签： c# entity-framework-6 asp.net-identity-2

【解决方案1】：

您所要做的就是从您的数据库中删除__MigrationHistory 表——它是在您注册第一个用户时由身份系统创建的。

当您有专门的数据库团队或数据库管理员时，不使用代码优先是有意义的 - 在这种情况下，应用程序开发人员不负责数据库工作。

【讨论】：