dotNET dotNET / Microsoft / Visual Studio
Сегодня про опыт (мой и моих коллег) и впечатления о .NET Core.
На всякий (почти невероятный) случай кратко о том, что это такое. Microsoft сделал фреймворк для кросcплатформенной разработки. Построил его на немного других принципах — сделал более гранулированным (говоря попросту — нарезали большие DLL-ки помельче), кое-что ещё поменяли.
В итоге имеем возможность писать более быстрые (в том числе, потому что не тянем лишнего) и компактные кроссплатформенные приложения. Проверяли под Windows и Linux — вполне работает. Маководов не было рядом :)
Есть и щедро разбросанные ложки дёгтя. Основная проблема — пока сыровато. 10 000 попугаев в секунду это, конечно, прикольно, но редко критично (по крайней мере, для бизнес-приложений). Давайте по порядку.
TL;DR В целом, новые проекты можно аккуратно пробовать делать на .NET Core, старые и большие я бы поостерёгся мигрировать.
Disclaimer: у меня Windows 10 + Visual Studio 2015, так что рассматриваю только этот случай и на данный момент времени. Поэтому через месяц-другой лучше свериться с сайтом.
Кстати, на сайте есть удобная и понятная инструкция о том, как начать работать. Я всё по ней сделал и не встретил никаких проблем. Правда, не все следуют инструкции. А зря.
Казалось бы, “это же .NET, что может случиться?” :) Как вам отсутствие в нём отправки писем? Да, есть сторонний пакет — MailKit. Однако, думаю, ситуация понятна. Возникает ощущение экосистемы Node.js, но вместо выбора из десятка пакетов для почти каждой задачи — один или ноль. Я немного утрирую, конечно, что-то есть.
Есть .NET Standard Library — попытка специфицировать общее API для обычного .NET и Core. Получится ли в итоге всё красиво и когда это будет, не берусь судить. Прорвёмся, я надеюсь.
Пока нормально получается писать под .NET Standard 1.3 (1.4 отличается незначительно). Но, временами, некоторые пакеты “хотят” 1.6 (не поддерживается обычным .NET). Для микросервисной архитектуры не очень критично (достаточно дёшево сделать хоть два мелких проекта под разные версии), для монолитной может быть печальнее.
В общем, ощущение, что очень уж хотелось сделать местами всё с нуля и круто и немного поторопились. Обратная совместимость? Ну, вы поняли. И с project.json как-то неудобно получилось…
Исторически сложилось, что мы используем TeamCity для билдов и NUnit для тестов. Мне, лично, ещё нравится, когда тесты можно из ReSharper запускать.
Если вкратце, из коробки просто так это всё не заработает. Про настройку билд-сервера рассказывать не буду, расскажу про настройку окружения для разработки.
Чтобы запускать тесты на NUnit из командной строки (dotnet test) или из студии, вам потребуется установить
dotnet-test-nunit.
В принципе, ничего сложного. Но если вы тоже работаете с TeamCity, не торопитесь набирать в Package Manager Console заветную строку:
На данный момент, интеграция с TeamCity будет вида “упал какой-то тест, курите логи”. В новой версии вроде должны починить. Поэтому, устанавливаем немного модифицированный пакет:
Повторюсь. В целом, новые проекты можно аккуратно пробовать делать на .NET Core. Старые и большие проекты я бы поостерёгся мигрировать.
И да, в микросервисной архитектуре будет немного проще сгладить некоторые “углы”. А для тех, кто никуда не торопится, можно попробовать подождать, когда .NET Core будет поддерживать .NET Standard 2.0.
dotNET dotNET / Microsoft / Visual Studio