Отдельное спасибо Мэтью Вилкину за любезную помощь в рецензировании этой статьи.
В последние годы Microsoft рекламировала каркас ASP.NET Core как будущее ASP.NET. ASP.NET Core представляет интерес для веб-профессионалов из стека Microsoft. Если вы запускаете веб-приложения в Windows и хотите выполнить обновление, что за ошибки? Является ли переход к последним и самым мощным и гладким?
В этой статье я хотел бы вникнуть в типичные подводные камни, с которыми вы можете столкнуться при обновлении до ASP.NET Core — при условии, что вы готовы сделать это. Как разработчикам, всегда интересно получить новые блестящие инструменты, которые облегчат вашу жизнь.
В этой статье я буду использовать «ASP.NET classic» для ссылки на устаревшую платформу ASP.NET. Я буду использовать «ASP.NET Core» для ссылки на стандартную среду, которую Microsoft предоставляет разработчикам ASP.NET.
Microsoft добилась значительных успехов в создании кроссплатформенного ядра ASP.NET. Новый инструментарий работает в Linux, macOS и Windows. Может быть приятно знать, что ваш внутренний код теперь работает где угодно. Это освобождает вас, разработчика, от необходимости кодировать на коробке Windows. Доступны новые инструменты для удовлетворения ваших личных предпочтений.
Исходя из ASP.NET classic, обоснованным предположением является то, что вы работаете на платформе Windows. Для вас переход кроссплатформенности может быть не актуален в данный момент. До сих пор ASP.NET classic была первоклассным гражданином и эксклюзивом для Windows. Такая тесная интеграция с Windows и IIS, безусловно, является и благословением, и проклятием.
Итак, что же означает ASP.NET Core для разработчиков на Windows Server и IIS? Теперь, когда ASP.NET Core является кроссплатформенным, каковы последствия?
Зависимость ада
Одним из естественных следствий отделения от IIS является взрыв зависимостей. ASP.NET Core работает на Kestrel, отдельном процессе, который отвечает на HTTP-запросы. Это означает, что фреймворк опирается на кучу зависимостей, где когда-то стоял IIS. Эти зависимости являются базовыми пакетами NuGet, которые можно загрузить из Интернета.
В ASP.NET Core NuGet является каноническим способом получения зависимостей. Фактически, большая часть инструментов теперь представляет собой разъединенный пакет NuGet, который вы можете добавить как зависимость. Инструменты, которые вы устанавливаете в своем локальном устройстве разработчика, — это всего лишь прокладка. Цель состоит в том, чтобы ваше приложение было автономным со всеми его зависимостями. Большинство ASP.NET Core поставляется в виде модульных пакетов NuGet, которые вы подключаете и играете.
Это новый взгляд на старую монолитную структуру, тесно связанную с IIS. ASP.NET Core является кроссплатформенным и означает это. То, что когда-то опиралось на колоссальные установки IIS и Windows, теперь сводится к пакету NuGet. Это делает структуру более гибкой и гибкой. Легче изменить небольшую зависимость NuGet, чем устанавливать модули на ваш веб-сервер.
Но, как это часто бывает, есть несколько ошибок:
- На локальном компьютере разработчика команда увидела папку пакетов NuGet с зависимостями на 1 ГБ.
- Если ваш сервер сборки находится за брандмауэром, вы загружаете каждую крошечную зависимость — утомительный процесс.
- По умолчанию в инструмент входят метапакеты, которые могут иметь посторонние зависимости.
Недостатком метапакетов является то, что если вы работаете в Windows, вы увидите странные зависимости, такие как:
В качестве зависимости не принято включать среду выполнения Linux и macOS, учитывая, что вы ожидаете запускать ее только в Windows. Тем не менее, если вы хотите пройти сборку, это необходимо. Есть способ уменьшить вашу зависимость, но не очень практичный в условиях предприятия. У немногих профессионалов есть время, чтобы настроить крошечные маленькие зависимости. Надежда на то, что в будущем инструмент станет лучше и нормализует зависимости.
Существуют определенные проблемы для успешной сборки на вашем сервере сборки. Моя команда и я чувствовали, что это катится на американских горках, к которым мы не подготовились. Из-за всех зависимостей в команде для ASP.NET Core кодовым названием было «Fat Lady».
Это оставляет нас с вопросом. Как вы получаете этот значительный каркас в веб-сервер?
Автоматизация развертывания
Если у вашей команды есть рабочие развертывания на ASP.NET classic, вы увидите, что многое изменилось. ASP.NET Core использует новый набор инструментов для развертываний.
Исходя из ASP.NET classic, надежда заключалась в том, что развертывания можно использовать повторно. В автоматизации есть набор сценариев, которые вы используете для внесения изменений на веб-сервер. Сценарии, которые выполняются в автоматизации, часто называют конвейером развертывания. В Windows это означает, что сценарии PowerShell обеспечивают надежное и предсказуемое развертывание. Наличие многоразовых трубопроводов — это один из способов обеспечения согласованного развертывания.
Инструменты ASP.NET Core используют отдельный набор инструментов командной строки для создания пакета развертывания. Здесь есть нюансы, которые заставят вас создать новый конвейер развертывания. Например, MS Build был предпочтительным инструментом CLI для классических развертываний ASP.NET. В ASP.NET Core есть dotnet publish Тонкие различия между ними приводят команду в новый конвейер. К сожалению, большая часть существующей автоматизации не была повторно использована.
Автоматика для ASP.NET classic сделала предположения, которые больше не действительны. Для нас целью было собрать воедино все необходимое для хорошего развертывания. Это заняло все руки на палубе, чтобы конкретизировать все необходимые детали.
Microsoft в последних выпусках ASP.NET Core добавила поддержку MS Build . Учитывая сроки, мы были слишком рано для этого объявления. Одна из идей — пересмотреть требования к развертыванию, прежде чем углубляться в ASP.NET Core. Выясните, какая часть вашего существующего трубопровода может использоваться повторно.
Ситуация на IIS практически такая же: изменений много. Windows Server и IIS нужен новый модуль для работы приложений ASP.NET Core. Хорошим решением является изоляция приложений ASP.NET Core от классических устаревших приложений. Необходимый модуль HTTP может негативно повлиять на классику ASP.NET. На работающем сервере убедитесь, что вы применили последние исправления и у вас есть время разобраться с любыми проблемами, пока сервер не работает. Существуют руководства по настройке ASP.NET Core в IIS.
Теперь, когда Fat Lady (ASP.NET Core) счастлива и работает, какие еще есть подводные камни?
Управляемый против неуправляемого кода
При автоматизации одной распространенной ошибкой является установка пула приложений на управляемый код. В ASP.NET Core это одна часть конфигурации, которую вы не можете использовать повторно. Одной из проблем, которая постоянно возникала во время развертываний, была установка пула приложений в неправильный режим. Если вы это сделаете, вы увидите сбой процесса с ошибкой 502.
Что может вызвать путаницу, так это то, что ASP.NET Core работает поверх стандартной платформы. Например, ASP.NET classic работает на классической платформе и в управляемом коде. В ASP.NET Core и IIS процесс, на котором размещается ваше веб-приложение, не выполняется ни на одной платформе. ASP.NET Core работает в отдельном процессе, отделенном от стандартной структуры.
Убедитесь, что для пула приложений установлен неуправляемый код. Если дважды щелкнуть пул приложений, он должен выглядеть следующим образом:
IIS запускает приложения ASP.NET Core как внешний процесс через обратный прокси-сервер. Это потому, что он больше не имеет тесной интеграции с IIS и является кроссплатформенным. Веб-сервер использует HTTP-модуль для отслеживания процесса. ASP.NET Core имеет все промежуточное программное обеспечение, необходимое для отправки HTTP-ответа, оно больше не зависит от IIS.
ASP.NET Classic Зависимости
Любая зависимость, которая отсутствует на ASP.NET Core, будет иметь последствия. В вашем списке зависимостей вы можете найти такую, которая зависит от классики ASP.NET. Все, что зависит от ASP.NET classic, нуждается в полной устаревшей среде для работы.
Microsoft сделала большие шаги к тому, чтобы сделать переход плавным. Для внешних популярных зависимостей вы часто найдете пакеты, которые работают с ASP.NET Core. Фреймворк ASP.NET Core содержит многие из тех же пакетов, которые вам уже знакомы. Это делает обновление более практичным и достижимым.
Например, ASP.NET Core имеет пакеты для Entity Framework, Dapper и ADO.NET. Эти пакеты похожи на свои аналоги в ASP.NET classic.
С внутренними зависимостями ситуация совершенно иная. Если у зависимости нет порта ядра ASP.NET, вам понадобится классика ASP.NET. ASP.NET Core и ASP.NET classic являются эксклюзивными. Это часто является слепым пятном для команд, желающих перейти на новую блестящую структуру.
Хорошим подходом является оценка вашего списка зависимостей и выяснение того, что зависит от чего. Выясните вашу иерархию зависимостей и изучите зависимости зависимости. Таким образом, вы заранее знаете, чего ожидать. Идея состоит в том, чтобы избежать неожиданностей, которые ведут себя непредсказуемым образом во время развертываний.
Если вам все еще нужен ASP.NET classic из-за зависимостей, можно запустить ASP.NET Core на устаревшей платформе. Но это добавляет больше риска для ваших развертываний, таких как работа с файлами cookie аутентификации .
Одна проблема заключается в том, что поведение по умолчанию, которое вы ожидаете от зависимостей, изменится. При подключении зависимостей ASP.NET Core убедитесь, что вы не делаете никаких предположений. Например, файл cookie аутентификации имеет другой набор настроек по умолчанию. ASP.NET Core в некоторых случаях полностью переписан, поэтому можно предположить, что поведение по умолчанию изменится. Не делайте никаких предположений, которые вы делали в ASP.NET classic. Протестируйте и проверьте все ваши зависимости.
Вывод
В целом, новый фреймворк, который вы получаете с ASP.NET Core, довольно приятный. Как разработчик, вы найдете лучший опыт написания кода. Инструменты упрощают структуру, и это доступно снаружи Visual Studio. Отключение от Windows и IIS — это шаг в правильном направлении.
С ASP.NET Core вы найдете более компактную структуру с меньшими затратами. Я нахожу инструменты CLI свежими и очень эффективными. Например, чтобы запустить все модульные тесты, выполните dotnet test Нет необходимости нажимать и расстраиваться в Visual Studio, чтобы получить обратную связь. Когда у вас есть куча тестов, обратная связь в Visual Studio часто медленная. Общий опыт написания кода — это то, что исходит из минималистской современной структуры.
Платформа ASP.NET Core MVC поставляется с улучшениями. Web API и MVC теперь представляют собой единую структуру. Вы наследуете от одного контроллера, чтобы использовать оба. Там нет путаницы в определении, какой из них использовать, что делает его более эффективным.
Как и все новые вещи, есть последствия для погружения прямо в безрассудство. Я надеюсь, что эта статья указывает на типичные подводные камни, которые вы хотя бы захотите рассмотреть. Лучше узнать, во что вы ввязываетесь, прежде чем начинать это новое приключение.