Мой первый опыт переноса .NET приложения под .NET Core
Совсем недавно я портировал .NET 4.5.2 – приложение под .NET Core 2.0. Хочу сразу отметить, что эта статья не является гайдом, и тем более это не перечень того, что может во время процесса пойти «не так». Однако она призвана дать общее понятие операции, мои впечатления от перехода на Core – стандарт и вообще, а стоит ли это делать.
Приложение
Приложение, которое я портировал, импортирует и обрабатывает информацию от ресурса SurveyMonkey. Проект DataPersistence – это уровень для взаимодействия с базой данных, в моем случае – через Entity Framework 6.2. Логика взаимодействия с SurveyMonkeys и преобразования данных так же, как и различные администрирующие функции, помещены в библиотеке ImporterCore. Importer – это небольшое консольное приложение, которое инкапсулирует определенную функциональность из ImporterCore, позволяя запустить ее в качестве запланированной Windows-задачи. Проект Explorer является веб-приложением ASP.NET MVC 5 для анализа информации. Проект Tests (на диаграмме не представлен) построен с использованием nUnit3 и обновляет все проекты к 5 версии.
Кратко о процессе
Сам порт занял у меня около двух дней. В конце концов картинка была следующая:
Более 80 процентов усилий были затрачены на чтение блогов, логов ошибок и, конечно же, употребление кофе. Но только после всего этого я смог собой гордиться. Впрочем, если бы мне пришлось повторить порт снова, сейчас бы он занял у меня всего лишь одну четвертую от того времени, которое я потратил. Итак, касательно порта я могу сказать следующее:
Просто погуглите готовые решения и применяйте их до тех пор, пока все это дело не заработает снова.- Для всех компонентов, кроме, собственно говоря, самого веб-проекта, обновите csproj-файлы к более новому и упрощенному VS15-формату, который все еще поддерживает версию .NET 4.5.2. Я подумал, что лучше сделать это вручную, чем пересоздавать проекты с нуля.
- Выгрузите все проекты из решения отдельно от DataPersistance, которая была в основании пирамиды приложения. Соберите для .NET Core – стандарта.
- Обновите все пакеты библиотеки DataPersistence к последним версиям, поддерживаемым .NET Core. В некоторых исключительных случаях (наподобие работы с Entity Framework) полностью замените пакеты программ на .NET Core – аналоги (в нашем случае это будет Entity Framework Core).
- Просмотрите все провальные билды и исправляйте все изменения api до тех пор, пока проект не скомпилировался.
- Повторите шаги 2-4, добавляя дополнительные пакеты к приложению (по одному за раз).
- Чтобы заставить заработать веб-проект после порта, мне пришлось бы столько всего фиксить и исправлять, что я просто предпочел создать новый пустой проект и просто скопировал папку контроллеров, моделей и представлений + различные статические файлы в виде JavaScript и CSS. Перенос сайта на новый проект вместо исправления старого было определенно правильным решением.
- Запустите тесты. Запомните, что «построение того же самого, что и раньше» - это не то же, что «делать то же самое, что и раньше».
- Исправьте баги шага 7.
- Проведите мануальные тесты.
Упущения
К сожалению, далеко не все прошло так гладко, как хотелось бы. В основном замеченные ошибки были связаны с не совсем правильным выполнением шагов 7 и 8.
Несовместимые библиотеки
Дело в том, что ImporterCore зависела от библиотеки, которую я написал несколько лет назад и которая не поддерживает стандарт .NET Core. Она использует WebClient, который не существует в рамках .NET Core 1.0 / 1.1. К счастью, уже в версии 2.0 появилась поддержка WebClient, что значительно упростило обновление системы – нужно всего лишь внести некоторые изменения в csproj, AssemblyInfo и nuspec – файлы. Однако в случае, если вы все же сильно зависите от неподдерживаемых библиотек, порт приложения будет невозможен.
Entity Framework
Эта вещь заняла больше всего времени. Дело в том, что Entity Framework 6.2 в .NET Core не поддерживался, а его аналог – Entity Framework Core – значительно различается, что делает процесс порта достаточно трудоемким. А именно:
- Маппинг
В конце концов EF Core мне понравился больше, чем EF 6.2. Здесь я привожу пример оригинального файла маппинга для оригинального объекта – Survey. Здесь Entity Framework получает информацию об именах колонок для всех свойств, названия таблицы, ключевом свойстве.
В EF Core при преобразовании свойства производится маппинг к соответствующей колонке (разве что вы не укажете другую логику маппинга). Также считается, что если в вашем классе вашей сущности есть свойство Id или SurveyId, это будет считаться свойством-ключом (опять же, если вы не укажете обратное). Так что мне удалось избежать написания около 1000 строк лишнего кода, что достаточно круто.
Большинство из оставшихся нюансов маппинга могут быть настроены через аннотации, композитные ключи и так далее.
Видео курсы по схожей тематике:
- Изменения в API
Здесь также есть целая серия замечательных изменений. К примеру, для конфигурирования «иностранных» ключей мы писали следующий код:
Однако в EF Core метод HasRequired() заменился на HasOne(). Также раньше для тестов приходилось использовать context.Database.Create() и context.Database.Delete(), которые в EF Core были заменены на context.Database.EnsureCreated() и context.Database.EnsureDeleted().
- Наложение
Немного больше усилий пришлось приложить, чтобы настроить кастомную работу со значениями типа DateTime. Приложение всегда сохраняет значения типа DateTime в базе как Utc, но когда EF читает это, указанный тип не распознается, таким образом он маркируется как DateTimeKind.Unspecified, что в последствии может приводить к нежелательным последствиям. В рамках предыдущей версии EF я использовал возможности фичи – Intersection, которая, увы, больше не доступна в полной мере в раках EF Core. Впрочем, я смог решить проблему при помощи использования инструмента EntityMaterializerSource.
Лично меня сводит с ума то, что ни одна версия Entity Framework – технологии не поддерживает в нормальном виде работу с UTC – форматом.
Lazy Loading
Это было наибольшее разочарование: EF Core не поддерживает Lazy Loading. Да, в грядущей версии EF 2.1 эта опция должна появиться, но на данный момент решения не существует. В свое время я написал немного горькой правды о производительности Entity Framework, потому использование возможностей Lazy Loading было бы разумным решением. Отследить правильность работы с базой во время построения приложения невозможно. К счастью, при помощи некоторых тестов мне удалось вовремя заметить, что EF Core не использовал возможности Lazy Loading, но представьте себе, что было бы, если бы я этого не заметил и выпустил приложение в продакшн.
Конечно, решение использовать Eager Loading вместо Lazy Loading не стало концом света, но оно вынудило писать большее количество тестов, усложнило код (в основном из-за использования вложенных Include() и ThenInclude() - конструкций) и слегка замедлило работу. Возможно, с релизом EF Core 2.1 я все же верну все так, как было.
Конфигурация
В то время, как .NET Framework хранит все записи о конфигурации в виде xml в app.config / web.config – файлах, .NET Core использует appsettings.json. Лично мне это понравилось, но вместе с этим мне пришлось внести некоторые изменения.
Хостинг на IIS
Оригинальный веб-сайт Explorer развернут под IIS. ASP.NET Core использует Kestrel, который запускается в качестве отдельного от IIS – процесса. Вам необходимо установить .NET Core Windows Server Hosting Bundle, что позволяет Kestrel непосредственно работать с кодом, а IIS – отвечать за безопасность и некоторые задачи администрирования. Также необходимо настроить пул приложения для запуска неуправляемого кода.
К несчастью, деплой подобного в продакшн – сложный и трудоемкий процесс. Пришлось ждать помощи от дружественно настроенного сисадмина. Упс.
Вердикт
По сути, я не встретил ничего особо страшного. Только парочку незначительных багов, каждый из которых потребовал немного времени на устранение. Для отслеживания подобных багов я советую использовать Portability Analyzer, который значительно упростит вам работу.
Бесплатные вебинары по схожей тематике:
Я портировал небольшое приложение – всего лишь 5 проектов с несколькими десятками тысяч строчек кода. Если я буду делать что-то подобное вновь, весь процесс должен занять у меня намного меньше времени, чем пара дней. А в целом перед портированием больших приложений я все же советую пока попрактиковаться на маленьких.
Вообще, если говорить о целесообразности перехода на стандарт .NET Core, я был вынужден это сделать только потому, что нам предстоит взаимодействовать с другими приложениями этого же стандарта. А так, безусловно, новая технология ASP.NET Core заслуживает своего внимания.
Автор перевода: Евгений Лукашук
Статьи по схожей тематике
