我首先使用实体框架代码开发了一个非常简单的网络应用程序。经过几个小时的挫折，我意识到即使 localdb 是 SQL Server Express，它实际上并不意味着在使用“发布”(发布向导)时用于生产。仅供引用，我使用的是 EF 6.1.3、SQL Server 2014、VS 2013 和 IIS 7。
如果我理解正确，当您单击使用 localdb 发布时，您实际上所做的就是将 localdb 数据库复制到您的 IIS 7 服务器。我无法弄清楚为什么当我通过 VS 迁移更新我的 lodaldb 数据库时，我的生产服务器数据库没有被更新。我理解(并且现在相信)它实际上是 localdb 的两个不同实例，因此不是相同的数据。
好吧，我已经完成了 localdb，我在我的机器上创建了一个真正的 SQL Server 2014 数据库。我在谷歌上搜索了几个小时，现在不知道该怎么做。我有一些问题:
如何使用 EF 管理这个新数据库？例如，假设我想添加一个新列。首先，我将它添加到我的 localdb，进行一些测试，然后使用 Add-Migration blah 进行迁移，然后使用 Update-Database ... 然后我是否必须使用 VS 生成 SQL 脚本，然后在生产数据库服务器上手动运行它？
我知道这不太好，但我可以不使用带有 Entity Framework 的本地数据库，而是将 EF 附加到一个真正的暂存 SQL Server 数据库(一个测试数据库)并跳过所有这些 localdb 牛*** *？那么我可以使用代码优先迁移来管理它并使所有内容保持同步吗？
我应该使用 Initializer 吗？我读过关于是否将这些用于生产数据库(比如这个)的相互矛盾的报告
公共(public)类 PricedNotesInitializer:MigrateDatabaseToLatestVersion<...,...> {
令人沮丧的是，我了解这些东西的唯一方法是通过其他沮丧的人的博客文章。我不明白为什么文档如此垃圾。
感谢您的帮助，对于您的咆哮，我们深表歉意。
最佳答案
使用初始化器
您可以使用 MigrateDatabaseToLatestVersion初始化程序，以便在部署后首次启动应用程序时自动完成对数据库的模式更改(如果可能，不会丢失数据)。
如果发生数据丢失，您将收到错误消息并且必须采取适当的措施。即使数据丢失，也可以覆盖它以继续。
开发环境搭建经验
正如其他答案已经指出的那样，每个环境都需要一个连接字符串，因此 LocalDB 适合开发，我什至鼓励它，因为它可以为任何新开发人员自动创建和初始化(并使用测试数据播种)需要通过从源代码构建和运行应用程序来开发或调试它。
除了加载解决方案、构建和运行代码库之外，“设置新的开发环境”体验应该尽可能流畅，手动步骤最少，最好是零。
自动化您的发布周期
您的部署和发布管道应该是自动的，不需要任何可能被错误执行、被遗忘或更糟的手动命令。
如果您想谨慎行事或满足某些合规性要求，手动步骤可能是对分阶段更改进行简单的是/否批准。
然而，您的暂存环境中的自动化测试应该可以缓解这种情况，并在成功时自动部署到生产环境中 - 在一个完美的世界中 ;)
针对生产手动运行 update-database 需要任何运行它的机器都可以访问生产数据库——我会说，如果您以交互方式运行它，这是不太可能或不推荐的情况。如果需要，您可以 script it作为自动部署管道的一部分，如果你想要比使用初始化器更多地控制它，这似乎最适合更简单的项目(虽然这个项目似乎是这样)。
关于c# - 首先使用生产数据库部署 Entity Framework 代码，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/39513211/