我目前正在调查迁移框架/工具的可能选项。我喜欢上面框架所基于的ruby迁移的想法。
所以我要求你的经验，意见以及他们之间的比较。你在生产中使用它们吗？
感谢您的回复。这个问题的目标是了解开发人员社区中哪些工具最常用，但似乎迁移不是热门话题。
无论如何，我已经决定使用MigSharp，因为代码库看起来很干净，并且很容易处理并且已经构建了对MS SQL CE的支持。第二名将是FluentMigrator，我无法为紧凑版制作一个工作示例。
干杯
答案 0 :(得分：10)
我在制作中使用FluentMigrator，并且是FM的长期贡献者。我认为你的问题是一般的;更加详细一些。此外，FM有一个谷歌组，如果你想要FM信息，它是相当活跃的。
我记得，FM来自migrator.net。它使用流畅的语法，并支持多个数据库。我们从rails迁移中获得了一些灵感，但它绝对不是一个端口。值得一试。我学到的一件事是不要将迁移放在与应用代码相同的程序集中。将它们分离到迁移程序集中，并使用它来迁移数据库。
此外，您应该始终在多个环境中工作，以避免迁移直接针对生产的问题。我总是至少有一个开发和生产环境，而且大多数时候也有一个测试环境。
答案 1 :(得分：3)
我使用mig＃。
它运作良好，但您需要有一些使用指南 - 因为迁移可能会变得复杂。
我们在迁移结束时使用序列号而不是日期时间戳。这是因为我们不知道何时设置了日期时间戳（当他们开始源代码更改集时;就在提交之前;有些时间在其间），不同的开发人员可以使用不同的方法。
Migration_0000034.cs等名称为您提供了充足的空间。
答案 2 :(得分：0)
此时，我会坚持使用migrator.net。我喜欢FluentMigrator的承诺，但似乎没有比migrator.net更好的活动开发（请参阅问题并拉取其github网站上的请求）。
执行ExecuteScalar（）也没有简单的方法。我会添加它，但我不想创建自己的fork，并且我认为没有理由拉动请求实际落在主服务器中。 （Execute.WithConnection是一个Action，所以它会按需激发，而不是在我需要它时触发）
所以对我来说，我要回到migrator.net。