c#：Fluent Migrator/MigSharp/migratordotnet 支持在 C# 代码中使用 Application.ProductVersion 进行版本编号吗？
我对使用其中一个产品进行迁移非常感兴趣，不仅在数据库中，而且在文件系统等中。
我最初的想法是我很想阅读 Application.ProductVersion 但它返回一个字符串，但大多数迁移都需要LONG 或类似的？
我不知道是否有人这样做，但我的想法是有两个不同版本的迁移。
1 迁移产品，即更改目录或文件系统中的内容等，我将使用 Application.ProductVersion
- 迁移数据库，我将使用我认为来自某个字段的数据库版本号？
有人这样用吗？
有什么想法哪个产品可以支持这样的事情吗？
我的迁移并不总是特定于数据库，有时也特定于应用程序。
目前的工作方式似乎每个新版本都必须是整数，即 1、2、3、4 等...并且不考虑次要版本、修订版本等。
期待任何见解
谢谢
I am very interested in using one of the products to do migration but not only in the database but also the file system etc.
My initial thought was i would love to read the Application.ProductVersion but it returns a string but most of the migrations need a LONG or similar?
I don't know if anybody is doing this, but my idea was having 2 distinct versions of the migrate.
1 to migrate the product i.e. Change directories, or things in the file system etc where i would use the Application.ProductVersion
- to migrate the database where i would use a version number of the database which I presume would come from a field?
Is anybody using it this way?
Any ideas which product would support something like this?
My migrations are not always database specific but sometimes application specific.
The way things work at the moment it appears that every new version would have to be a whole number i.e. 1, 2, 3 , 4 etc... and doesn't take into account minor, revisions etc..
Look forward to any insight
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
MigratorDotNet 不要求版本号是连续的（实际上，他们当前的建议是使用长整型格式的时间戳）。因此，如果您确定主要版本永远不会包含超过两位数字，次要版本永远不会包含超过四位数字，并且内部版本号和修订号永远不会包含超过五位数字，您可以将其组合成一个长的。例如，2.34.1023.86 将变为 0200340102300086。如果您的下一个版本是 2.42.0.2 (0200420000000002)，迁移引擎将处理该问题。虽然感觉有点像黑客（尽管我喜欢），但它应该可以创建一个带有实际操作文件系统等的“迁移”的单独程序集。但是，您可能需要一个单独的数据库来包含MigratorDotNet 使用 SchemaInfo 表来跟踪所应用的版本。类似的黑客可能适用于其他迁移产品。
MigratorDotNet doesn't require that the version numbers be consecutive (actually, their current recommendation is to use timestamps formatted as longs). So if you are e.g. sure that the major version will never contain more than two digits, the minor version will never contain more than four, and the build number and revision number will never contain more than five digits each, you could combine this into a long. For example, 2.34.1023.86 would become 0200340102300086. If your next version is 2.42.0.2 (0200420000000002), the migration engine will handle that. Although it feels like a bit of a hack (albeit one that I like), it should work to create a separate assembly with "migrations" that actually manipulate the file system etc. However, you'd possibly need a separate database to contain the SchemaInfo table that MigratorDotNet uses to keep track of the applied versions. Similar hacks could probably work with other migration products.
在 MigSharp 中，您还可以选择使用 long 作为时间戳。因此，Aasmund 的建议也适用于 Mig#。在 Mig# 2.1 版本中，您可以选择完全自定义时间戳格式（只要您可以从中计算出 long）。
因此，如果对于任何给定时刻（即数据库版本），文件系统和数据库模式的外观都有一个已定义的状态，那么您可以使用迁移框架并让迁移执行文件系统和/或数据库上所需的任何内容。如果您只想在一次迁移中更改文件系统，那么就这样做。在这种情况下，数据库将仅更新以保存最新的迁移版本号。
In MigSharp, you can also choose to used a long as a timestamp. So, Aasmund's suggestion would work with Mig# too. In version 2.1 of Mig# you will have the option of completely customizing the timestamp format (as long as you can compute a long from it).
So, if for any given moment (i.e. database version) there's a defined state of how your filesystem and database schema should look like, then you can use a migration framework and have the migration execute whatever is needed on the filesystem and/or the database. If you want to only change the filesystem in one migration, then do so. In this case, the database will then only be updated to hold the latest migration version number.