Entity Framework 4.3.1 всегда запускает все миграции на Update-Database - PullRequest
Новая
       45

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

4 голосов
/ 16 марта 2012

Я создал начальную миграцию с 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), но я не уверен, что проблема есть. Может быть, я упускаю что-то тривиальное?

Ответы [ 2 ]

3 голосов
/ 16 марта 2012

Проблема была решена после связи с DevArt .Я никогда не вызывал обходной путь IgnoreSchemaName в классе Configuration, который был сгенерирован при запуске 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 дает более подробную информацию о конфигурации.

1 голос
/ 18 марта 2014

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

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

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

...