Start Debugging

EF Core 11 позволяет создать и применить миграцию одной командой

Команда dotnet ef database update теперь принимает --add для создания и применения миграции в одном шаге. Вот как это работает, почему это важно для контейнеров и .NET Aspire, и на что обратить внимание.

Если вы когда-либо переключались между dotnet ef migrations add и dotnet ef database update десятки раз в течение сессии прототипирования, у EF Core 11 Preview 2 есть небольшой выигрыш в качестве жизни: флаг --add для database update.

Одна команда вместо двух

Новый рабочий процесс сворачивает двухшаговый танец в один вызов:

dotnet ef database update InitialCreate --add

Эта команда создаёт миграцию с именем InitialCreate, компилирует её с помощью Roslyn во время выполнения и применяет к базе данных. Файлы миграции по-прежнему оказываются на диске, поэтому попадают в систему контроля версий, как любая другая миграция.

Если вам нужно настроить выходной каталог или пространство имён, те же опции от migrations add переносятся:

dotnet ef database update AddProducts --add \
  --output-dir Migrations/Products \
  --namespace MyApp.Migrations

Пользователи PowerShell получают эквивалентный переключатель -Add для Update-Database:

Update-Database -Migration InitialCreate -Add

Почему важна компиляция во время выполнения

Реальная выгода — это не сохранение нескольких нажатий клавиш в локальной разработке. Это включение рабочих процессов миграций в средах, где перекомпиляция не вариант.

Подумайте об оркестрации .NET Aspire или контейнеризированных CI-конвейерах: скомпилированный проект уже запечён в образ. Без --add вам понадобился бы отдельный шаг сборки, только чтобы создать миграцию, перекомпилировать проект, а затем применить её. С компиляцией Roslyn во время выполнения команда database update обрабатывает весь жизненный цикл на месте.

Удаление миграции в offline-режиме

EF Core 11 также добавляет флаг --offline к migrations remove. Если база данных недоступна или вы точно знаете, что миграция никогда не применялась, вы можете полностью пропустить проверку соединения:

dotnet ef migrations remove --offline

Обратите внимание, что --offline и --force взаимоисключающи: --force нуждается в активном соединении, чтобы проверить, была ли миграция применена, прежде чем откатить её.

Обе команды теперь также принимают параметр --connection, поэтому вы можете нацелиться на конкретную базу данных, не трогая конфигурацию вашего DbContext:

dotnet ef migrations remove --connection "Server=staging;Database=App;..."

Когда к этому прибегать

Для прототипирования и разработки внутреннего цикла --add устраняет трение. Для конвейеров развёртывания на основе контейнеров он устраняет целую стадию сборки. Просто имейте в виду, что миграции, скомпилированные во время выполнения, обходят ваши обычные предупреждения сборки, поэтому относитесь к сгенерированным файлам как к артефактам, которые всё же заслуживают обзора, прежде чем попасть в main.

Полные детали в документации новинок EF Core 11.

< Назад