migrate.exe на сервере сборки хочет "начать заново" с миграциями

Question

Часть нашего автоматизированного процесса сборки включает запуск migrate.exe для обновления тестовых баз данных до последней версии базы данных.

Процесс относительно прост:

1. Скопируйте файл migrate.exe в папку /bin компилируемого проекта.
2. Запустите файл migrate.exe со строкой подключения (указанной как часть определения сборки).

Пример второго шага (отредактированный, очевидно) будет:

migrate.exe Company.Data.dll /connectionString="Server=...;Database=...;User Id=...;Password=..." 
                             /connectionProviderName="System.Data.SqlClient"

где Company.Data.dll - только что созданный вывод проекта, компилируемого на сервере сборки.

Этот процесс был в течение нескольких месяцев и работал нормально. До сегодняшнего дня.

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

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

Если я извлекаю код из системы управления исходным кодом, собираю его и запускаю сам файл migrate.exe локально (с той же строкой подключения), он действует надлежащим образом (сначала выполняется только та миграция, которая должна, а затем при последующих попытках говорится, что не было ожидающих явных миграций),

Мне кажется, что если строка подключения была указана на нужную базу данных, а имя производного от DbContext класса, используемого для EF, совпадает с тем, что находится в таблице __MigrationHistory, migrate.exe должен иметь возможность находить записи, а не запустить эти миграции.

Что еще мне не хватает, что я должен посмотреть?

Обновление: я только что это произошло, когда указал на другую базу данных на том же сервере. Тот же "обходной путь" (локальный запуск migrate.exe). Просто интересно отметить, что это происходило точно так же, когда указывалось на другую базу данных.

Answer 1

Я думаю, что у меня есть решение, я получил ту же проблему. Оказалось, проблема с разрешениями SQL. Пользователю службы сервера сборки необходимы разрешения на чтение / запись и ddladmin, чтобы миграция работала. В моей ситуации администратор базы данных изменил разрешения пользователя службы только на ddladmin, но процесс миграции должен выполнять чтение и запись в таблицы истории миграции. Поскольку он не мог прочитать историю миграции, он предполагал, что ему необходимо применить все миграции. Это были разные разрешения между моей учетной записью и учетной записью службы сборки. Надеюсь, это кому-нибудь поможет.