Я получил несколько проектов с использованием Asp.Net Ядро 1.0 и Entity Framework Ядро 1.1.0Применить миграцию EF на публикацию доступны только для некоторых веб-проектов
У меня есть код первого подхода миграции и я публикую в Azure через Visual Studio 2015.
Как я применял миграцию в Azure Sql Server, был включен флажок публикации: «Entity Framework Migrations - применить эту миграцию при публикации», где я ввел строку подключения.
Я обновил несколько пакетов, и теперь для одного из моих проектов я не вижу, чтобы этот вариант применил миграцию в публикации больше. Я могу видеть, что он пытается обнаружить контексты данных, но он не находит ничего (хотя там в том же проекте ..)
Смотрите ниже:
проект, где я могу применить миграции на Azure при публикации:
проект, где при публикации исчезает возможность применить миграции на Azure:
Я подозреваю, что это связано с некоторыми версиями зависимостей для проекта, а не с моей IDE, потому что я использую ту же Visual Studio (обновление 2015 года) для обоих проектов.
Не удалось найти информацию об этом. Какая зависимость позволяет этот вариант? Если я выясню, какая версия проблематична, тогда остается вопрос, как применять миграцию при публикации?
Оба проекта имеют миграции в веб-проекта и оба проекта используют "Microsoft.AspNetCore.Identity.EntityFrameworkCore": "1.1.0"
UPDATE 1: Мне удалось найти то, что в этом замешан. Кажется, что если я использую эти зависимости:
"Microsoft.EntityFrameworkCore.Tools": "1.0.0-preview2-final",
"Microsoft.EntityFrameworkCore.Design": "1.0.0-preview2-final"
Visual Studio может найти контекст данных и предлагают возможность применить миграции на публикацию. Но если я использую более новые версии этих зависимостей, как:
"Microsoft.EntityFrameworkCore.Tools": "1.1.0-preview4-final",
"Microsoft.EntityFrameworkCore.Design": "1.1.0"
Тогда этот вариант для применения миграции исчезает и ВС не может найти какой-либо контекст данных при публикации.
Мне нужно узнать, что нового в статусе миграции и Asp.Net Core.
Просто из любопытства: В чем проблема с вызовом 'dbcontext.Database.MigrateAsync()' при запуске приложения? Когда вы разворачиваете его на azure, и вы используете слоты для развертывания, он будет развертывать приложение, а затем пинговать его один раз, чтобы убедиться, что его разогрели, прежде чем заменять его производственным слотом. – Tseng
В этом разделе есть несколько дискуссий. Лично мне нравится, чтобы миграция применялась до развертывания приложения, так что если миграция не применима, не было бы проблем с текущим приложением и БД в процессе производства. Хотя, если он входит в код как часть Startup, это означает, что приложение нужно будет сначала развернуть, а затем применить миграцию. Если эта миграция не будет применена, приложение перестанет работать и придется повторно развернуть предыдущую версию. Но я мог бы подумать об использовании 'dbcontext.Database.MigrateAsync()', если для этого есть хорошие аргументы? – iberodev
Ну, вот почему я упоминаю слоты развертывания Azure: docs.microsoft.com/en-us/azure/app-service-web/web-sites-staged-publishing См. Https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-staged-publishing (особенно часть «Swap with preview (multi-phase swap)»). Вы в основном публикуете приложение в промежуточном слоте, вы можете вызвать разминку (вызвать некоторый url, который заставляет IIS запускать ваше приложение), а затем начать переключение между ними. Я думаю, вы также можете настроить его только для изменения, если URL-адрес для разминки был успешным, но не знаю его точно. – Tseng