Entity Framework 4.3.1 always run all migrations on Update-Database

Question

I have created an initial migration with Add-Migration. When I run Update-Database on an empty DB it creates all tables, including adding an entry in the __MigrationHistory table.

Now I run Update-Database again just to test, and instead of "No changes detected" I get this:

PM> Update-Database -Verbose -Project testProject.Web
Using StartUp project 'testProject.Web'.
Target database is: 'testProject_dbo' (DataSource: localhost, Provider: Devart.Data.MySql, Origin: Explicit).
Applying explicit migrations: [201203151243164_Start].
Applying explicit migration: 201203151243164_Start.
CREATE TABLE attachments ( 
 ...table data...
)
Table 'attachments' already exists
Table 'attachments' already exists

It seems like the update is unaware of the current DB state. The only solution is to delete all tables and update. That works also if I add more migrations.

As you see, I am using a different database provider than usual (Devart.Data.Mysql), but I'm not sure if the problem is there. Maybe I'm missing something trivial?

Answer 1

The problem was resolved after communicating with DevArt. I never called the IgnoreSchemaName workaround in the Configuration class that was generated when running Enable-Migrations. To summarize, this is the class that made it work finally:

internal sealed class Configuration : DbMigrationsConfiguration<YourDbContext>
{
    public Configuration()
    {
        // Because the Package Manager Console (NuGet) instantiates YourDbContext with the empty constructor,
        // a custom connection must be specified. Based on http://www.devart.com/blogs/dotconnect/?p=5603
        // Note that the MySqlProviderFactory must also be present in Web.config or App.config in the *startup project*
        // for this to work! Configuration example:

        /*
          <system.data>
            <DbProviderFactories>
              <clear />
              <remove invariant="Devart.Data.MySql" />
              <add name="dotConnect for MySQL" invariant="Devart.Data.MySql" description="Devart dotConnect for MySQL" type="Devart.Data.MySql.MySqlProviderFactory, Devart.Data.MySql, Version=6.30.196.0, Culture=neutral, PublicKeyToken=09af7300eec23701" />
            </DbProviderFactories>
          </system.data>
        */

        // Apply the IgnoreSchemaName workaround
        MySqlEntityProviderConfig.Instance.Workarounds.IgnoreSchemaName = true;

        // Create a custom connection to specify the database and set a SQL generator for MySql.
        var connectionInfo = MySqlConnectionInfo.CreateConnection("<Your ConnectionString>");

        TargetDatabase = connectionInfo;
        SetSqlGenerator(connectionInfo.GetInvariantName(), new MySqlEntityMigrationSqlGenerator());

        // Enable automatic migrations if you like
        AutomaticMigrationsEnabled = false;

        // There is some problem with referencing EntityFramework 4.3.1.0 for me, so another fix that needs
        // to be applied in Web.config is this:

        /*
          <runtime>
            <assemblyBinding>
              <!-- This redirection is needed for EntityFramework Migrations through the Package Manager Console (NuGet) -->
              <dependentAssembly>
                <assemblyIdentity name="EntityFramework" publicKeyToken="b77a5c561934e089" />
                <bindingRedirect oldVersion="4.3.0.0" newVersion="4.3.1.0" />
              </dependentAssembly>
            </assemblyBinding>
          </runtime>
        */

        // After these Web.config additions, running migrations in Package Manager Console should be as easy as:
        // Update-Database -Verbose -ProjectName Your.MigrationsProject

        // Creating new migrations:
        // Add-Migration -Name MigrationDescription -ProjectName Your.MigrationsProject
    }
}

After that I emptied the database one more time to generate a correct migration history entry, and everything was fine. DevArt gives more details about the configuration.

Answer 2

I had the same odd behaviour, but in my case it turned out to be much simpler: a code merge had reset my Startup Project to the default, which was not the project that contained the migrations.

I didn't notice until I tried the -Verbose flag, which explicitly laid out that my Startup project was not the same as the NuGet project configured in Package Manager.

Worth the sanity check!