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