c#: Fluent Migrator/MigSharp/migratordotnet support version numbering with Application.ProductVersion in C# code?

Question

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

1. 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

Answer 1

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.

Answer 2

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.