Как обрабатывать огромные файлы дизайнеров миграции efcore, которые замедляют сборку и IDE

Question

В настоящее время у меня есть проект efcore 2.1 с около 230 сущностями и около 350 миграций. Каждый раз, когда я добавляю efcore миграцию, создается файл конструктора. Этот файл составляет около 535 КБ и увеличивается (всего 150 МБ для всех файлов дизайнеров). Это делает IDE медленным и не отвечает, рефакторинг не нужен, он также замедляет процесс сборки. Если я удаляю все файлы дизайнеров, сборка снижается со 110 до 20 секунд, и среда IDE снова становится быстрой.

однако, как только я удаляю все дизайнерские файлы, я не могу работать с командой "dotnet ef database".

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

Мне любопытно, есть ли другие проекты с такой же проблемой, и как они работают вокруг этого?

Answer 1

Теперь, в будущем, можно добавить .editorconfigв папку Migrations со следующим содержимым:

# All files
# Sets generated code for all migrations
[*]
generated_code = true

Это отключит все анализаторы, что сделает мою IDE более счастливой со всеми миграциями.

Примечание: требуется Visual Studio 16.5

Answer 2

Вы можете использовать другие сборки для управления миграциями.

Answer 3

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

Answer 4

Я думаю, что ваш вопрос дублирует Рекомендуемый способ очистки старых миграций Entity Framework Core и Entity Framework Core: безопасно ли удалить Migration.Designer.cs, если мы никогда не вернем миграцию?. Вся тема обсуждается в различных ответах на эти темы.

Я предлагаю обдумать свой ответ, чтобы снова получить работоспособность вашей IDE и сократить время компиляции. И в долгосрочной перспективе кажется хорошей практикой время от времени объединять все миграции в одну. Если в вашем случае это не срочно, вы можете дождаться появления этой функции (запланированной в.NET 6), которая позволит вам сделать это более простым способом.