С момента релиза .NET Core 1.0, который пришёлся на 27 июня 2016 года, прошёл год. За это время успел произойти ряд важных событий. Хочется подвести некоторые итоги. Понять, что же нам принесла новая инкарнация .NET? Что поменялось? Что стало лучше?
Что сразу становится заметно — так это то, что если раньше решения на базе .NET были строго отделены от технологий и инструментов мира *nix, то теперь платформа .NET Core начала активно ассимилировать все наработки *nix-стека. И уже .NET-программисты активно работают с Linux-серверами, используют SSH, разворачивают docker-контейнеры, а одним из самых популярных веб-серверов для .NET стал nginx. Еще лет пять назад подобная ситуация казалась бы чем-то из разряда фантастики, но сегодня это уже свершившаяся реальность.
Фреска «Scuola di Atene»Рафаэля Санти
События
Переход на новыйстарыйобновлённый тип файла проекта
С момента выхода первых версий .NET Core тип файла проекта у этой платформы отличался от такового у классического .NET. Если в .NET classic мы работали с .csproj-проектами, то в .NET Core было сразу два проектных файла — project.json и project_name.xproj. Первый файл, как не трудно догадаться, — это файл в формате JSON, который использовался при работе со средами отличными от Windows. Файл в формате xproj использовался (или генерировался в случае отсутствия) Visual Studio. Сама ситуация наличия двух файлов была довольно странной и вносила беспорядок при синхронизации файлов проекта. Также при комбинировании в одном решении проектов на базе классического .NET и .NET Core часто могли возникать ошибки при сборке проекта. Чтобы решить возникшую проблему, Microsoft принял решение разрубить Гордиев узел, и с релизом Visual Studio 2017 объявил project.json и .xproj устаревшими форматами и вернул старый тип проекта .csproj Стоит правда отметить, что старый тип проекта оказался не таким уж и старым. .сsproj файлы для .NET Core отличаются от .csproj для классического .NET гораздо меньшим количеством содержания и упрощённой структурой.
В релиз ушла Visual Studio for Mac
Думаю многие, кто занимается разработкой под мобильные устройства, не пропустили одно из самых значимых событий в этой сфере, произошедшее в феврале прошлого года — покупку компании Xamarin компанией Microsoft. Значимо оно в первую очередь тем, что если раньше технологии Xamarin были «решением со стороны» (3rd party solution), то теперь они стали частью стека .NET и развиваются в рамках платформы, что само по себе достаточно хороший сигнал для компаний и разработчиков. И вот, спустя полтора года, на базе Xamarin Studio (который в свою очередь был создан на базе Mono Develop) Microsoft выпускает Visual Studio for Mac, которая из коробки содержит весь необходимый инструментарий для разработки под .NET Core.
Драма совместимости
Эпичный тред возник на кануне Build 2017. В трекере репозитория ASP.NET Coreбыл заведен баг под названием «The new ASP.NET Core 2.0 packages can no longer be used on .NET Desktop». Намерение Microsoft убрать возможность разрабатывать ASP.NET Core приложения под .NET 4.x очень сильно взволновало сообщество, поскольку такое изменение могло бы нарушить главную концепцию платформы — совместимость и преемственность. Впрочем, выдержав интригу несколько дней, на Build 2017 компания Microsoft сообщила, что не будет ломать совместимость, и разработчики смогут и дальше комбинировать разные версии фреймворка.
Какие преимущества на сегодняшний день уже получили .NET Core разработчики?
Дешевизна хостинга
За счёт того, что проекты на базе .NET Core можно запускать не только на серверах под управлением Windows Server, но и на Linux-based серверах, стоимость хостинга может стать гораздо ниже. Во-первых, VPS под управлением Linux не включают в себя дополнительную плату за лицензирование ОС. Во-вторых, системные требования у Linux-систем обычно немного ниже и бюджетный проект может рассчитывать на вполне приемлемую производительность на достаточно скромных аппаратных ресурсах. Так, например, Digital Ocean даёт возможность размещения проекта на полноценном VPS-сервере с SSD-диском всего за $5 в месяц.
Поддержка контейнеризации
Учитывая, что Linux поддерживает контейнеризацию, проекты на .NET Core также очень легко контейнеризировать. Впрочем, сейчас команды Microsoft и Docker активно работают над реализацией Docker for Windows, однако пока что это решение находится ещё только на этапе разработки, а Docker для Linux — уже стабильный продукт с длительной историей. Стоит также отметить, что на Hub.Docker.comуже опубликованыофициальные образы .NET Core от Microsoft. Причем образы есть как под Windows Nano Server, так и под Linux.
Кроссплатформенная разработка
Создав практически идеальную IDE под Windows, Microsoft решила не останавливаться на достигнутом и войти на новые для себя платформы. Так кроссплатформенный VS Code давно уже перерос формат обычного текстового редактора с подсветкой синтаксиса и все ближе приближается к полноценной IDE. Кроме того, для mac OS поддерживается Visual Studio for Mac OS, о которой я писал выше.
Впрочем, у MS на этом поле появился серьёзный конкурент. JetBrains хоть и не вывел свой Rider релиз, но за прошедший год он уже стал практически готовым к работе инструментом.
Набор инструментов для .NET Core разработчиков на разных платформах теперь выглядит так:
Гомогенность среды
Используя решения на базе .NET Core, в одинаковом выигрыше находятся как компании, которые сделали ставку на Windows Server, так и компании, инфраструктура которых основана на Linux. И те, и другие могут использовать привычные инструменты для развертывания, масштабирования, мониторинга. По достоинству оценят это преимущество, конечно же, devops-инженеры.
Преемственность
Одно из главных преимуществ новой версии платформы — это возможность плавного перехода. Несмотря на глобальные изменения фреймворка и тулинга, процесс перехода на новую платформу может быть организован достаточно плавно. В случае, если есть понимание преимуществ от перехода на новую платформу, но не все подключаемые библиотеки поддерживают .NET Standard, всегда есть возможность начать разработку .NET Core проекта с таргетингом на .NET 4.x. Такой подход позволяет использовать преимущества нового типа файлов проекта .csproj и подключать как библиотеки, реализующие .NET Standard, так и библиотеки .NET 4.x. Таким образом, архитектурно ваше приложение уже будет готово к работе под .NET Core, и как только все подключаемые библиотеки получат совместимость с .NET Standard, вам нужно будет только переключить таргетинг проекта.
Использовать или нет?
Стоит ли переводить на .NET Core уже существующие проекты?
It depends. Скорее всего, портировать крупный работающий проект будет не выгодно чисто финансово. Разве что вы точно знаете, какие именно из возможностей .NET Core помогут вашему продукту в будущем получить существенные преимущества. А вот писать новые модули на .NET Core будет вполне оправданным решением.
Стоит ли разрабатывать на .NET Core новый проект?
Если все требующиеся для проекта библиотеки портированы под .NET Core — однозначно, да. Если какие-то из библиотек ещё не портированы, то как уже было сказано выше, всегда можно начать новый проект на базе .NET Core с таргетингом на версию 4.6.1 и использовать как core-библиотеки, так и библиотеки под .NET 4.x.
Подводя итоги
Если в прошлой своей статьея писал, что основная сфера применения .NET Core — стартапы и небольшие проекты, то теперь с уверенностью могу сказать, что .NET Core уже готов к применению в highload проектах. Крупные компании, нуждающиеся в корпоративных решениях, в принципе также могут начинать реализацию проектов на этой платформе, но учитывая то, насколько это консервативный сегмент, ожидать массовое появление enterprise-решений на базе .NET Core стоит примерно через
P.S. Если вы заинтересовались разработкой под .NET Core и хотите быть в курсе новостей и тенденций платформы, приглашаю вас присоединиться к сообществу украинских .NET Core разработчиков — .NET Core Ukraine User Group. В сообществе можно обмениваться полезной информацией и сообща находить ответы на возникающие вопросы.