Entity Framework 4.3.1 всегда запускает все миграции в Update-Database

Question

Я создал начальную миграцию с Add-Migration. Когда я запускаю Update-Database на пустой БД, он создает все таблицы, включая добавление записи в таблицу __MigrationHistory.

Теперь я бегу Update-Database снова только, чтобы проверить, и вместо того, чтобы «не обнаружено изменений», я получаю это:

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 

Похоже, что обновление не знает о текущем состоянии БД. Единственное решение - удалить все таблицы и обновить их. Это также работает, если я добавлю дополнительные миграции.

Как вы видите, я использую другой поставщик баз данных, чем обычно (Devart.Data.Mysql), но я не уверен, есть ли проблема. Может, мне не хватает чего-то тривиального?

Answer 1

Проблема была решена после связи с DevArt. Я никогда не вызывал обходной путь IgnoreSchemaName в классе конфигурации, который был сгенерирован при запуске Enable-Migrations. Подводя итог, это класс, который сделал его работу наконец:

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

После этого я опустел к базе данных еще раз, чтобы генерировать правильную запись истории миграции, и все было хорошо. DevArt дает более подробную информацию о конфигурации.

Answer 2

У меня было такое же странное поведение, но в моем случае это оказалось намного проще: слияние кода сбросило мой проект запуска по умолчанию, который не был проектом, который содержал миграции.

Я не заметил, пока не попробовал флаг -Verbose, в котором явно указано, что мой проект запуска не совпадает с проектом NuGet, настроенным в диспетчере пакетов.

Стоит проверить здравый смысл!