.NET Core и Visual Studio

dotNET dotNET  /  Microsoft  /  Visual Studio

Сегодня про опыт (мой и моих коллег) и впечатления о .NET Core.

На всякий (почти невероятный) случай кратко о том, что это такое. Microsoft сделал фреймворк для кросcплатформенной разработки. Построил его на немного других принципах — сделал более гранулированным (говоря попросту — нарезали большие DLL-ки помельче), кое-что ещё поменяли.

В итоге имеем возможность писать более быстрые (в том числе, потому что не тянем лишнего) и компактные кроссплатформенные приложения. Проверяли под Windows и Linux — вполне работает. Маководов не было рядом :)

Есть и щедро разбросанные ложки дёгтя. Основная проблема — пока сыровато. 10 000 попугаев в секунду это, конечно, прикольно, но редко критично (по крайней мере, для бизнес-приложений). Давайте по порядку.

TL;DR В целом, новые проекты можно аккуратно пробовать делать на .NET Core, старые и большие я бы поостерёгся мигрировать.

Установка

Disclaimer: у меня Windows 10 + Visual Studio 2015, так что рассматриваю только этот случай и на данный момент времени. Поэтому через месяц-другой лучше свериться с сайтом.

Кстати, на сайте есть удобная и понятная инструкция о том, как начать работать. Я всё по ней сделал и не встретил никаких проблем. Правда, не все следуют инструкции. А зря.

  1. Скачайте и установите Visual Studio 2015 Update 3 если у вас установлена более старая VS 2015. Нет, не так. ОБЯЗАТЕЛЬНО СНАЧАЛА УСТАНОВИТЕ, чтобы потом не тратить время на последствия.
  2. Скачайте и установите .NET Core 1.0.1 tools Preview 2.
  3. Не лишним будет сразу скачать и установить .NET Core 1.0.3 SDK (LTS). Или .NET Core 1.1 SDK. Не факт, что потребуется, но вероятность хорошая.

“Зрелость” экосистемы

Казалось бы, “это же .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 заветную строку:

Install-Package dotnet-test-nunit -Pre

На данный момент, интеграция с TeamCity будет вида “упал какой-то тест, курите логи”. В новой версии вроде должны починить. Поэтому, устанавливаем немного модифицированный пакет:

Install-Package dotnet-test-nunit-teamcity -Pre

Резюме

Повторюсь. В целом, новые проекты можно аккуратно пробовать делать на .NET Core. Старые и большие проекты я бы поостерёгся мигрировать.

И да, в микросервисной архитектуре будет немного проще сгладить некоторые “углы”. А для тех, кто никуда не торопится, можно попробовать подождать, когда .NET Core будет поддерживать .NET Standard 2.0.

dotNET dotNET  /  Microsoft  /  Visual Studio