EF 4.3.1 always run all migrations on Update-Database

[ciscoheat]

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:

Code: Select all

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.

I have followed the instructions in the blog post and everything works up to this point, so I'm not sure if the problem is in EF or the MySql connector. Any ideas?

[ciscoheat]

More tests reveal that using the default provider (connecting to .\SQLEXPRESS) works, as it gives me the message "No pending explicit migrations." if I execute Update-Database more than once.

[Shalex]

The most probable reason is that you are putting the IgnoreSchemaName workaround in an inappropriate place. We recommend you to set it in a static constructor of your DbContext-descendant or in any other place where it would be called even when using Package Manager Console. Refer to http://www.devart.com/blogs/dotconnect/ ... qlite.html.

Package Manager Console compiles a project (but doen't run it) and uses only DbContext-descendant.

The DatabaseExists check applies full mapping of the model, but Code-First Migrations uses only mapping which is defined in migrations.

[ciscoheat]

Yes, that was exactly the reason! I called the workaround in the DI configuration in my auto-migration setup, but not in the class that was instantiated when executing Update-Database from the console. Thank you!

[ciscoheat]

Here is the class that was the result of my endeavors:

Code: Select all

internal sealed class Configuration : DbMigrationsConfiguration
{
    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:

        /*
          
            
              
              
              
            
          
        */

        // 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("");

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

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

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

        /*
          
              
              
                
                
              
            
          
        */

        // 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
    }
}