Как отключить первые миграции кода

86

В EF5 у меня есть модель сущности с первым кодом. Но я хочу управлять изменениями базы данных вручную - я не хочу, чтобы EF изменяла мою существующую базу данных и все ее данные. Но когда я делаю параллельные изменения в сопоставлении EF и в базе данных, EF отказывается работать должным образом, говоря мне, что мне нужно использовать первую миграцию кода. Как мне это выключить?

entity-framework migration code-first

— Стэн Харгроув
источник

Возможный дубликат Как отключить миграцию в Entity Framework 6.0

— Майкл Фрейдгейм,

102

установите для Database.SetInitializer значение null.

public class DatabaseContext: DbContext
{
    //the base accepts the name of the connection string provided in the web.config as a parameter
    public DatabaseContext()
        : base("DatabaseContext")
    {
        //disable initializer
        Database.SetInitializer<DatabaseContext>(null);
    }

— Сарат Рачури
источник

2

Установка инициализатора в конструкторе экземпляра контекста не имеет смысла. EF вызовет инициализатор, прежде чем фактически перейдет к этому коду, если вы попытаетесь создать новый контекст.

— Jcl

1

Просто проверил ответ, посмотрев на «Инструмент диагностики» в VS 2017. Вызовы ADO.NET перед первым желаемым SQL-запросом остановились после установки инициализатора в значение null в конструкторе.

— Karl

2

Работает как положено. Это правда, что EF вызовет инициализатор раньше, но затем вызов его снова внутри конструктора заставляет DbContext просто игнорировать миграции, если вы хотите игнорировать тот факт, что у вас __MigrationHistoryнет последней миграции, и вы не хотите сделай это все равно. В моем случае я использую миграции в среде разработки, но при развертывании в производственной среде я использую SSDT для обновления базы данных. Поэтому EF будет жаловаться, что модель изменилась, потому __MigrationHistoryчто не будет последней миграции, но я могу гарантировать, что база данных обновлена.

— Alisson

Я бы посоветовал переместить вызов Database.SetInitializerиз конструктора в конструктор класса. Это гарантирует, что вызов будет сделан только один раз.

— Стивен

41

Итак, наиболее полный ответ, который я нашел, таков:

Удалите Migrationsпапку внутри вашего проекта.
Установите Database.SetInitializer<DatabaseContext>(null);внутри вашего инициализатора DatabaseContext.
Удалите таблицу __MigrationHistoryвнутри вашей базы данных. Для EF6 + таблица находится под, Tablesно для более ранних версий она расположена под System Tables.
Собери и беги.
Прибыль.

— Карлинген
источник

К сожалению, после выполнения этих шагов EF6 по-прежнему проверяет наличие __MigrationHistoryкаждого запуска моего приложения, что увеличивает время запуска моего приложения на несколько миллисекунд. Есть ли способ __MigrationHistoryполностью отключить проверку?

— Дай

27

Если вы хотите полностью отключить миграции:

https://stackoverflow.com/a/9709407/141172

Тем не менее, я счел, что лучше оставить первую миграцию кода включенной, но использовать -Scriptопцию, чтобы EF создал для меня сценарий изменения БД, который я могу применить к каждой базе данных (разработка, контроль качества, производство) вручную:

Update-Database -Script -ProjectName MyProject -StartupProjectName MyProject

Таким образом, EF создаст для меня сценарий изменений, и я по-прежнему полностью контролирую применяемые изменения. Я редактирую сценарии изменений, как и любой другой исходный код.

— Эрик Дж.
источник

1

ваша ссылка действительно не соответствует completely turn off migrations. Для этого: добавьте Database.SetInitializer<YourContextType>(null)в автозагрузку своего приложения

— Дон Чидл

Есть идеи, как этого добиться с помощью EF Core?

— Шимми Вайцхандлер

@Shimmy: EF Core никогда не должен автоматически пытаться изменить вашу базу данных. См. Github.com/dotnet/efcore/issues/3152

— Эрик Дж.

26

Если вы уже использовали миграции, изменение только инициализатора не поможет. Вам нужно перейти в Management Studio, открыть таблицы базы данных, перейти в System Tablesпапку и удалить __MigrationHistoryтаблицу, которая там находится (для EF6 и выше, она расположена непосредственно под Tables). Это навсегда отключит миграцию.

— Эпизодекс
источник

7

Таблица __MigrationHistory находится непосредственно под таблицами, а не в системных таблицах.

— Питер Хедберг

6

@PeterHedberg Это верно для EF6 +. Для более ранних версий это было под System Tables.

— Эпизодекс

1

Вы также можете переименовать таблицу вместо ее удаления, используя sp_rename. Еще я отключил инициализатор.

— NMrt

2

Я только что решил эту "проблему"

Удаление таблицы "_MigrationHistory" из базы данных.
Удаление папки «Миграции» из проекта.
Обновление файла EDMX.
Очистите проект и перестройте его.

Конфигурация моей среды следующая

1. Visual Studio 2017 15.8.2
2. ASP NET MVC project
3. .NET Framework 4.6.1
4. Entity Framework 6.2.0

— ДмитрийБойко
источник

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

— dalcam

Что, если позже нам понадобятся миграции, создаст ли он новую _MigrationHistoryтаблицу автоматически?

— sairfan