Как сделать миграцию asp net core

Обновлено: 07.07.2024

Asp Net Core - это как Проктор энд Гэмбл т.е. два в одном флаконе: фрэймворк и Web-сервер, а само веб приложение имеет вид консольного приложения, развертываемого через IWebHost с предварительной настройкой сервисов, миддлваре и т.п. Все относительно просто в случаях, когда разработка идет на машине с установленной Visual Studio. Для запуска веб приложений в Asp Net Core используется веб-сервер Kestrel. И, казалось, бы нет никаких сложностей для запуска веб-приложения на IIS. Но, столкнувшись с такой задачей я набил кучу шишек, о чем и хочу рассказать в этом посте.

Как известно в IIS имеются пулы, которые, используются во-первых, для изоляции одних приложений от других, а, во-вторых, для простоты настройки однотипных приложений. И если запустить настройку пула приложения на IIS, то можно увидеть, что Net Core в нем напрочь отсутствует (предварительно я установил Net Core Sdk), всего 3 варианта таргет фрэймворка для пула: 2.0, 4.0 и неуправляемый код. Для Asp Net Core нужно выбрать последний.

Кроме всего этого в Web.config необходимо указать использование этого модуля и путь к целевой сборке (приложению), например, мое приложение - E3App.Web.dll и Web.Config имеет следующий вид:

Этот файл, как и многое другое, генерируется в процессе публикации проекта (Publish), однако, я не думал, что он играет роль, т.к. он в явном виде отсутствует в проекте. Но он очень важный! Особенно атрибут stdoutLogEnabled, по умолчанию этот атрибут имеет значение false, что для разработчика означает следующее: любое исключение произошедшее при запуске приложение будет "проглочено", а в качестве результата мы увидим на странице что-то вроде: "Оопс, а что-то сломалось". Включаем и идем дальше.

Следующим приколом на пути к запуску приложения стала сама БД: я поставил Sql Server 2012, предполагая, что EF нет дела до версии SQL сервера, но не тут-то было (хотя мне казалось, что ву меня был рабочий проект под 12 версию сервера). Текст исключения в стандартном выводе мне ничего не говорил о том, почему у меня ломается приложение при старте. Однако, подозрительным было то, что при отладке приложение стартовало без каких-либо проблем, а на IIS - ломалось. Тогда я решил заменить 12 SQL Server на SQL Server 2016 и вуаля, текст ошибки стал другим. Теперь приложение жаловалось на то, что нет прав на создании новой БД при подключении к таблице master (тут все тривиально, нужна роль sysadmin для пользователя под которым выполняется подключение). Хотелось бы сделать ремарку о том, что EF работает с БД по парадигме Code First (сам создает скрипт для создания БД, всех таблиц и связей между ними). Тут тоже пришлось помучиться, т.к. можно сделать строку подключения с полным указаниям логина и пароля (в appsettings.json):

Но это не всегда удобно использовать заранее созданную учетную запись, иногда необходимо использовать Windows-аутентификацию, казалось бы просто выдал права (роль sysadmin) своей Windows учетной записи:

но нет в БД, оказывается, EF лезет через другую учетку. Экспериментальным способом включая данную роль у логинов по очереди, определил, что это учетная запись BULTIN\Users (а если посмотреть, кто создал БД - IIS APPPOOL/AspNetCore).

Казалось бы тривиальная задача, но она отняла у меня кучу времени, я убил, наверное, пару дней чистого времени пытаясь понять, что происходит и почему все работает не так, как нужно. Надеюсь, что этот пост поможет тем, кто столкнулся с такой же проблемой: деплоя на IIS Asp Net Core веб приложения.

Generic Host

global.json

Полную версию кода приложения вы можете посмотреть в нашем репозитории на GitHub.

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

Хотя справедливости ради стоит отметить, что при запуске приложения на Linux все равно будет использоваться модель внепроцессного размещения веб-сервера.
И еще, если вы размещаете на своем сервере несколько приложений с внутрипроцессной моделью, вы должны позаботиться о том, чтобы каждое такое приложение имело свой собственный пул.

Маршрутизация Endpoint Routing

EndpointRoutingMiddleware тут определяется, какая конечная точка будет вызвана для каждого пути URL запроса, по сути выполняя роль маршрутизации
EndpointMiddleware вызывает конечную точку

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

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

Подробное описание вы можете найти в документации.

Замеры производительности в приложении

Время прохождения теста стало быстрее примерно на 20% (меньше лучше)

Среднее время отклика (Average) быстрее примерно на 13.7% (меньше лучше)

Количество запросов на единицу времени, т.е. пропускная способность (throughput) увеличилось на 12.7% (больше лучше)

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

Стартовое потребление памяти практически не изменилось, показания изменяются в пределах погрешности измерений.

1 - Архитектура MVC

2 - Функциональность Razor Pages

С применением Razor Pages каждая веб-страница становится автономной с компонентом View, код также четко налажен.

3 - Обеспечение поддержки популярных JavaScript-фреймворков

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

4 - Улучшение совместной работы и кросс-платформенной поддержки

Проще говоря, ваши разработчики могут работать в Linux, MacOS или Windows и при этом они по-прежнему могут совместно работать над одним проектом. Это возможно благодаря унифицированной документации, которую предлагает среда разработки Visual Studio.

5 - Встроенная поддержка внедрения зависимостей

Автор перевода: Елена Теплицкая. Источник

*Копирование материала возможно только с ссылкой на источник и указанием автора материала. Благодарим за уважение интеллектуальных прав собственности.TQM systems

Видеоурок

Если разрабатываемое ПО заточено под Linux или Mac OS, скорее всего выбор падёт на расширенные редактор Visual Studio Code. При этом ничего не мешает использовать его и в Windows. В пределах данного материала предпочтение отдаём разработке в VS 2017. Достаточный функционал есть и у VS 2015.

Только после указания необходимых дополнений можем начать инсталляцию Visual Studio.

Здесь появляется выбор среди двух разновидностей проектов:

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

Сразу после этого отображается окно, в котором нас просят выбрать подходящий для работы шаблон:

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

Empty: создаёт чистый шаблон без дополнительных функций. Применяется для написания приложений с чистого листа;
Web API: проект веб-службы;
Web Application: в качестве обработчика запросов проект применяет Razor Pages;
Web Application: проект, построенный на архитектуре модель-вид-контроллер;
Angular: работает на Angular 2+ ;
Reat js: основа - React.JS ;
Reat JS and Redux: строится на React JS и Redux ;
Razor Class Library: проект, заточенный под разработку с Razor.

Ещё здесь присутствует возможность указания метода аутентификации и подключения Docker-контейнера.

Для лучшего понимания проекта, мы расскажем о базовых элементах структуры в стандартном примере. У шаблона Empty элементарная структура – это как раз тот минимум, который нужен для пуска любого приложения.

Connected Services: список синхронизированных сервисов Azure;
Dependencies: все встроенные библиотеки, скрипты или проще – зависимости;
wwwroot: узел применяется для сохранения файлов-констант, которые не меняются в процессе работы. Сюда относятся JS-скрипты, CSS-файлы, картинки и прочее. Всё перечисленное находится в одноимённой папке. Данный каталог вынесен отдельным элементом в проект для простоты установки уровней доступа к файлам. Таким образом легко разрешить доступ к картинкам сервера, но запретить – к скриптам;
Program.cs: ключевой файл создаваемого ПО, именно он обрабатывается в первую очередь. Код отсюда выполняет настройку и запуск веб-хоста в пределах приложения;
Startup.cs: файл для установки класса Startup. В нём обычно размещается логика работы с поступающими запросами.

Читайте также: