Entity Framework 4.3.1 always runs all migrations in Update-Database

I created an initial migration using Add-Migration . When I run Update-Database in an empty database, it creates all the tables, including adding an entry to the __MigrationHistory table.

Now I run Update-Database again just for verification, and instead of "No Change" I get the following:

 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 that the update does not know about the current state of the database. The only solution is to delete all the tables and update them. This also works if I add additional migrations.

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

+4
source share
2 answers

The problem was resolved after contacting DevArt . I never called the IgnoreSchemaName in the configuration class that was generated when Enable-Migrations started. To summarize, this is the class that made it work permanently:

 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 again to create the correct record of the migration history, and everything was in order. DevArt provides more detailed configuration information.

+3
source

I had the same strange behavior, but in my case it turned out to be much simpler: as a result of code merging, my default startup project was reset, which was not a project that contained migrations.

I did not notice until I tried the -Verbose flag, which explicitly states that my launch project does not match the NuGet project configured in the package manager.

It is worth checking common sense!

+1
source

Source: https://habr.com/ru/post/1401694/


All Articles