FluentMigrator migration succeeds, but no changes to DB

Question

I must be missing something pretty basic.

I'm working on a legacy project, and I'm trying to bring FluentMigrator into the mix cause I've got some interesting database changes and data migrations coming up that I think will be made much easier by using this tool.

For the initial migration, I just want to bring the database up to the current production version, as-is. To simplify the initial migration, I scripted out my SQL Server 2008 database, and the migration executes the scripted commands as a series of SQL commands.

To test it out, I create an entirely empty database, and try to run it from command line using this:

> migrate -a "C:\My\Project\Path\bin\debug\Rds.MyProjName.DBMigrations.dll" 
-db SqlServer2008 -conn "Data Source=.\SQLEXPRESS2008;Initial Catalog=myNewDbName;
Integrated Security=SSPI" -version=20100901000000

The version specified is the timestamp on the first migration class's Migration attribute.

At the command line, everything appears to run fine - the the entire script zooms by, and it ends with:

-- CreateProductionDbCircaSep2010: migrated

However, when I take a look at the database, it is still empty. Absolutely nothing is in there. My Up method looks like this:

public override void Up()
{
    var cmds = LoadEmbeddedResources
        .GetEmbeddedResource("scripted_db_2010-09-01.sql")
        .AsString()
        .ParseCommands();

    foreach (var c in cmds) {
        Execute.Sql(c);
    }

    CreateReferenceData();
}

(FYI, I'm parsing the script instead of running it as-is because I started by using Migrator.Net before discovering it was dead, and this was already set up.)

Can anyone give me a hand? It almost appears like a transaction isn't committing, or some command-line option to have the migration do a dry- run is turned on, but I don't see it...

EDIT:Additional things I've tried

To confirm that the connection string was using the database I expect it to, I renamed the database and afterwards got a login error, as expected.

For further tests, I cut down the length of the script, and tried executing it using

public override void Up()
{
    Execute.Script(@"..\Resources\test.sql"); 
}

instead of command-by-command, but I get the same results. Here is the output on that test (note, I edited the pathes and such):

C:\My\Project\Path\FluentMigrator.Net\ >migrate -a "C:\My\Project\Path\bin\debug
\My.Project.DBMigrations.dll" -db SqlServer2008 -conn "Data Source=.\SQLEXPRESS2
008;Initial Catalog=myNewDbName;Integrated Security=SSPI" -version=2010090100000
0
Using Database SqlServer2008 and Connection String Data Source=.\SQLEXPRESS2008;
Initial Catalog=myNewDbName;Integrated Security=SSPI
-- VersionMigration: migrating ===============================================

-- CreateTable VersionInfo
-- VersionMigration: migrated
-- CreateProductionDbCircaSep2010: migrating =================================

-- ExecuteSqlScript C:\My\Project\Path\FluentMigrator.Net\..\Resources\test.sql
-- CreateProductionDbCircaSep2010: migrated

Yet no tables in the database - there isn't even the expected VersionInfo table.

Answer 1

I found that if your dbconnection string is null, this same will happen. Wrong db connstring:crash, no migration tags found: crash.. but null db string.. silently do nothing but look and report that migrations worked. Be warned.

Answer 2

Old question, but I'll add this tip as this is the stackoverflow article google led me to searching for the problem. Maybe it will help someone.

Did you remember to clear the VersionInfo table when wiping the database?

If you have dropped all the tables in the database, and expect the tool to re-create the database from scratch, but it simply does nothing, you might have forgot to clear / drop the VersionInfo table. FluentMigrator will then look in the VersionInfo table, find the everything is applied, and correctly conclude to do absolutely nothing. Let's say a... ahem... good friend told me this tip...

Answer 3

After some investigation and testing with both version 0.8 and 1.0, it appears this is a bug in FluentMigrator.Net related to the migration runner's transaction management - if you run a migration with a specific version number, the transaction's commit never gets called; if you don't specify a version number, it's fine.

EDIT:

I have since submitted a patch to the project which was accepted. This is no longer a problem.

Answer 4

This sounds really stupid, but I wasted several hours on it, so it belongs here:

Make sure your migration classes use public visibility.

Without this, your migrations will be completely ignored.