Масааки Имаи (автор концепции Кайдзен)
Кроссплатформенность — одно из основных требований для приложения на рынке. Большая часть современных языков программирования кроссплатформенны, однако, почти на всех языках разработчик сталкивается с проблемой совместимости его ПО с той или иной системой. Приходится компилировать свой проект под конкретную операционную систему или вести разработку проекта под среду исполнения интерпретируемого языка.
Среда исполнения .NET позволяет разрабатывать кроссплатформенное ПО используя промежуточный код (байт код). .NET выглядит лучшим, на мой взгляд, решением для разработки кроссплатформенного ПО. Однако, как и у всех других, у этого решения есть свои недостатки. Их призван устранить .NET Standard.
Как это было
Рассмотри несколько платформ .NET. Во-первых, .NET Framework — доступна только под Windows, нельзя запустить среду исполнения на других операционных системах. Во-вторых, Mono/Xamarin — это действительно кроссплатформенное решение, поддерживающее Mac, IOS, Android. Из недостатков — отсутствие полной совместимости с .NET Framework, вследствие чего приходится вырезать куски кода из проекта при портировании в Mono/Xamarin. Ещё одна платформа, которая появилась совсем недавно — .NET Core. Она позволяет разрабатывать и запускать серверное кроссплатформенное ПО под Windows, Linux, Mac, Docker.
Даже при большом разнообразии и покрытии операционных систем, разрабатываемая программа может быть не кроссплатформенной, т.к. сами платформы совместимы не полностью. Решение есть — разрабатываем ядро полностью совместимое со всеми платформами и дописываем недостающие части. А как определить, что совместимо, а что нет? Остаётся только тратить время на изучение документаций и API этих платформ.
Portable Class Library — предок .Net Standard Library
Portable Class Library (PCL) — инструмент для разработки кроссплатформенной библиотеки. При создании проекта необходимо выбрать список платформ и приступить к разработке. Изначально PCL поддерживала только Windows и Windows Phone. Вскорости Microsoft приобрел Xamarin, что сразу привнесло поддержку Xamarin в PCL. По мере разработки .NET Core, также появилась поддержка этой платформы в PCL. Платформ становится всё больше — следовательно PCL, как пересечение платформ, становится всё меньше. Microsoft решила предложить альтернативное решение.
Новая платформа .NET Standard Library
Microsoft добавляет новую платформу .NET Standard Library. Первая мысль: «теперь нужно ещё больше читать документации, чтобы проект работал и на этой платформе тоже». Как оказалось, это не так. .NET Standard Library — формальный набор спецификаций общих интерфейсов других платформ: .NET Core, .NET Framework, Mono/Xamarin и остальных. Библиотеки, удовлетворяющие спецификациям .NET Standard, могут быть использованы на различных платформах .NET. Фактически, Standard гарантирует возможность использования библиотек в разных средах исполнения, он приносит универсальность, которой так не хватало, в экосистему .NET.
.NET Standard изменяет архитектуру приложений, он располагается как слой между общей инфраструктурой .NET и конечными платформами.
Выделить кроссплатформенное ядро приложения стало гораздо проще. Достаточно, чтобы ядро собиралось под Standard. Также, в этом ядре можно использовать любые другие библиотеки .NET Standard. Новая прослойка является куратором для будущих платформ. Новые платформы должны будут соответствовать .NET Standard, а не наоборот, как это было с PCL.
Свой Standard под каждую платформу
.NET Standard Library различаются по версиям — каждая версия имеет полную совместимость с следующей (что нельзя сказать о PCL). Обратной совместимости нет. При выборе более высокой версии будет доступно большее количество API для разработки библиотеки. Однако, это означает, что меньше платформ будут поддерживать разрабатываемую библиотеку. Ниже приведена таблица разных версий .NET Standard (таблица составлена для Release версии .NET Standard).
| Target Platform Name | Alias | |||||||
|---|---|---|---|---|---|---|---|---|
| .NET Standard | netstandard | 1.0 | 1.1 | 1.2 | 1.3 | 1.4 | 1.5 | 1.6 |
| .NET Core | netcoreapp | > | > | > | > | > | > | 1.0 |
| .NET Framework | net | > | 4.5 | 4.5.2 4.5.1 |
4.6 | 4.6.1 | 4.6.2 | 4.6.3 |
| Universal Windows Platform | uap | > | > | > | > | 10.0 | ||
| Windows | win | > | 8.0 | 8.1 | ||||
| Windows Phone | wpa | > | > | 8.1 | ||||
| Windows Phone Silverlight | wp | 8.1 8.0 |
||||||
| Mono/Xamarin Platforms | > | > | > | > | > | > | * | |
| Mono | > | > | * |
В первой строке приведены номера версий .NET Standard Library. В каждой следующей строке указана платформа и версия, которая может использовать библиотеку, написанную с использованием соответствующего Standard. Стрелки указывают на совместимость данной версии Standard с следующей ячейкой в той же строке.
Примеры:
- Если библиотека удовлетворяет спецификациям .NET Standard 1.3, то она может быть использована только на платформах: .NET Framework 4.6 (и более новыми), .NET Core, Universal Windows Platform 10 (UWP) и Mono/Xamarin.
- Если библиотека пишется под Standard 1.3, то в ней можно использовать другие библиотеки, которые написаны с использованием версий Standard: 1.0, 1.1, 1.2, 1.3.
Понимание .NET Standard Library
.NET Standard Library можно представить в виде абстрактных множеств, каждое следующие будет содержать предыдущее и добавлять, что-то своё, покрывая больше кода платформ .NET. Соответственно, их размер будет увеличиваться по мере увеличения номера версии.
C каждой новой версией функционал ядра приложения будет расти, однако, многие возможности «полноценных» платформ будут не доступны. Посмотрим на изображения других множеств: .NET Framework, .NET Core, Mono/Xamarin:
.NET Standard одной и той же версии покрывает идентичное множество кода этих платформ. И находится целиком внутри их пересечения. Ядро приложения будет находится внутри центрального круга. Само приложение лучше разделить на три части для реализации поддержки других платформ. Таким образом, готовый продукт будет работать сразу на трёх платформах и на нескольких операционных системах.
Плюсы использования .NET Standard Library:
- Кроссплатформенность, несколько платформ .NET, несколько операционных систем.
- Поддержка кода — проект будет проще поддерживать после релиза, добавляя в него новый функционал без портирования.
- Гарантия работы — очередная библиотека из Nuget под .NET Standard точно будет работать на нескольких операционных системах.
Минусы использования .NET Standard Library:
- Ограничения по функционалу из коробки — .NET Standard продолжает развиваться.
- Сложности с переносом под .NET Standard уже существующих проектов.
Заключение
.NET Standard Library является хорошей заменой неудобной библиотеки Portable Class Library. Standard Library гораздо лучше в плане кроссплатформенности. Теперь можно без больших проблем выделить кроссплатформенное ядро приложения или разработать кроссплатформенную библиотеку, удовлетворяющие спецификациям .NET Standard. Затем написать нужные интерфейсы под необходимые операционные системы и получить готовый продукт.
Комментарии (35)
Naboy
07.11.2016 19:43Есть подозрение, что это WinRT вызовы которые стали доступны для вызова в Windows 8/8.1, например Windows.Storage
MonkAlex
07.11.2016 20:00А где это реально указывается? Это проекты типа '.Net Standart` теперь можно создавать или что?
raptor
07.11.2016 21:02В файле project.json. Да, по умолчанию в .net core все class library создаются под netstandart1.6.
MonkAlex
07.11.2016 21:16Я наверно чего-то не понимаю, но project.json же только для dotNet_Core? А остальные?
raptor
07.11.2016 21:24Да с введением всех этих стандартов путаница усилилась. И надо время, что бы разобраться теперь во всем что MS и сообщество сделали за эти пару лет. Особенно вся хрень с переименованиями платформ, стандартов, металиб и т.п.
Вы можете создать проект .netCore указать, что весь код совместим с netstandart1.6 и собрать его. Потом, сборку — вы можете использовать во всех проектах, которые будут совместимы с netstandart1.6 в том числе и c .NET Framework.
Ostrea
07.11.2016 22:39Внутри project.json указываются таргет фреймворки, так что он не только для dotNet Core.
PaGrom
08.11.2016 01:05+1По последним новостям, MS отказывается от project.json и возвращается к csproj и msbuild. https://blogs.msdn.microsoft.com/dotnet/2016/10/19/net-core-tooling-in-visual-studio-15/
crea7or
08.11.2016 17:19Что их так колбасит-то. То туда, то сюда. Причём по разным проектам же видно.
AlexLysenko
16.02.2017 11:00+1Увы, никак. Одной рукой — только экранной не раскладывая клавиатуру. Клавиатура задумывалась, как альтернатива для продуктивной работы, поэтому сценарий работы на ходу одной рукой не был приоритетным.
dimka11
07.11.2016 23:36Почему бы просто не портировать .net framework для macos/Linux?!
EngineerSpock
07.11.2016 23:45+3Что вы подразумеваете под «портировать»? Как я понимаю, собственно, .NET Core и есть попытка запилить как можно более широкую кроссплатформенную часть.
PaGrom
08.11.2016 01:07MS говорили, что портировать почти невозможно, поэтому просто написали все заново раздробив на мелкие кусочки так, что бы больше не приходилось ставить на машину отдельно фреймворк, чтобы запустить приложение. Так .NET Core появился.
gandjustas
08.11.2016 01:29+4Чета много написано, а суть .NET Standard простая. До него в .NET Standard явно указывались совместимые платформы. Вышла новая платформа или версия — пересобирай либу, публикуй новую версию пакета
После появления .NET Standard в PCL указывается не версия платформы, а версия стандарта. И проекты под все совместимые с этой версией стандарта платформы могут либу добавить.
Ну и вторая причина — так как стандарт развивается раньше конкретных платформ, то платформы будут стремиться соответствовать стандарту. В идеале (где-то в районе .NET Std3)это будет один и тот же код на всех платформах.
petuhov_k
08.11.2016 04:46+3Microsoft добавляет новую платформу .NET Standard Library. [..] .NET Standard Library — формальный набор спецификаций общих интерфейсов
И всё-таки, .NET Standard Library — это платформа, библиотека (library) или набор спецификаций?
centur
08.11.2016 08:26+6Самое понятное объяснение что такое .NET Standard я видел у David Fowler вот тут
melt
08.11.2016 10:20+2Если кто пропустил, то есть анонс .NET Standard 2.0 на Хабре. Из особенностей — был откат изменений, поэтому новый стандарт совместим с .NET Framework 4.6.1, а не 4.6.3.
slonopotamus
08.11.2016 11:51+2.NET выглядит лучшим, на мой взгляд, решением для разработки кроссплатформенного ПО
Обоснуйте.
Razaz
09.11.2016 00:45+5Просто выскажу своё мнение(серверсайд). Это сугубо ИМХО :)
1. Java — непонятно, что будет дальше. Oracle как-то не внушает доверия, да и JCP ИМХО тормозит развитие. Хотя к ней я не равнодушен :)
2. Go — для больших приложений ну его нафиг. Пусть дженерики сделают и динамическую подгрузку либ :)
3. Ruby(RoR) — это было весело в районе 1.9-2.0. Закидоны DHH поднадоели.
4. Python — ничего плохого не скажу. Просто не лежит душа и не хочу соваться в native interop для некоторых задачек. Да и вакханалия с версиями удручает.
5. Scala — достаточно нишевая, дико бесит долгая сборка. C# активно добавляет некоторые её фичи.
6. JS — для высокопроизводительного бэкенда с большой долей compute — сразу до свидания. Изоморфный рендеринг пусть на отдельном бэкенде рисуют если так прижало :)
7. PHP — свои мысли оставлю при себе :)
Остальные как-то сильно специфичны или мало распространены.
На текущий момент я вижу три основных проблемы:
1. Негатив к MS и просто незнание текущего состояния дел.
2. Небольшой размер активного open-source комьюнити. Тут дела идут на поправку, но это чувствуется.
3. Много «тру-энтерпрайз» разработчиков, которые дальше пузыря MS не видят и сидят в своём мирке. Для них дикость, что можно выкинуть EF, не использовать SqlServer, поменять MVC на Nancy, так как они ждут что эти решения примет за них MS.
Сорри, если кого обидел случайно, просто личные наблюдения :)
0xd34df00d
09.11.2016 20:16Кроссплатформенный серверсайд вполне можно писать на стандартных плюсах, например.
Но это тоже сугубо ИМХО и личный опыт.raptor
10.11.2016 14:55Только вот реально времени это займет больше. И дальнейшая поддержка дороже выйдет. Все-таки, что не говори, а С# и Java в плане скорости разработки, особенно под энтерпрайз, ушли существенно дальше чем C++.
0xd34df00d
10.11.2016 21:15У меня есть небольшой опыт разработки на C# и большой опыт разработки на плюсах. И я, признаться, не очень понимаю, почему специалист по C++ и специалист по C# должны писать с существенно разной скоростью, особенно если бизнес-логика достаточно серьёзная.
Ну и на C++ производительный код писать легче, да.
Стоимость программиста будет, вероятно, выше, да, но я как программист не буду сильно протестовать.
ad1Dima
14.11.2016 11:04Простое отсутствие стандартной библиотеки в C++ уже усложняет разработку. Да есть сторонние, куча их, несовместимых между собой. Самая боль — строки.
Да, понятно, что на проекте выбирается определённый набор библиотек под стандартные задачи, но если разработчик меняется, приходит новый, то тут дополнительные расходы на знакомство с текущим набором библиотек под простейшие задачи, в худшем случае разработчику придётся учиться работать с новой библиотекой. А если где-то в процессе пойдёт сбой, так и вообще свою библиотеку подтянет, с которой уже работал.
Синтаксический сахар для асинхронной работы: в C# можно писать асинхронный код, будто он последовательный. Ну и куча таких мелочей.0xd34df00d
14.11.2016 20:20Вообще-то хотя бы просто формально STL — стандартная библиотека. Даже со строками.
Boost можно, кстати, считать вполне себе стандартом де-факто для квалифицированного разработчика на C++.
Ну и async/await в C++17 уже завезли. И не в любом сервер-сайде это нужно, кстати, мягко скажем.Razaz
14.11.2016 23:04Ничего не имею против C++, но в большом бэкенд проекте я бы отдал предпочтение type safe(хотя бы почти) языку — проще найти людей, люди стоят дешевле, меньше способов выстрелить себе в ногу(особенно при наличии junior разработчиков). Плюс в том же C# всегда можно уйти в unsafe, если сильно припекло :D Ну и тот же CoreRT пилят.
C++ 17 вроде как — «nearly feature-complete».
Хорошо хоть memory model завезли ;)
ad1Dima
15.11.2016 08:18Я сейчас конечно не бекенд ковыряю, но реально кроссплатформенную тулу на C++ которая работает на всех десктоп и мобильный осях. И это ад. Во многом, конечно, из-за того, что код тянется с 90х. Там куча задефайненных флагов под разные платформы. И там собственная реализация строк. Хорошо, если во всех нужных вам зависимостях будет использоваться STL, а если нет? Зоопарк зависимостей.
Кстати, на iOS эта штука ходит в интернет через Obj-C, вероятно потому что все стандартизировано и универсально.
>Ну и async/await в C++17 уже завезли.
Даже в C#, где компилятор можно считать один, прошло 3-4 года, пока нормально обновились большинство библиотек с поддержкой этой фичи, и стало комфортно пользоваться ей.
Вспомнить менеджеры зависимостей ещё. (да, я знаю, есть альтернативы для плюсов, но стандарта нет даже де-факто).
Это все мелочи, но каждая потенциально отъедает время. За счёт этого у Java и C# скорость разработки и выше. Понятно, что это во многом зависит и от разработчиков и от внутренних процессов. Но средний результат будет такой.
DjoNIK
Эта совместимость гарантируется на бинарном уровне или на уровне API?
DjoNIK
Похоже, глупость спросил. Ибо если не бинарная совместимость, то как мы сможем использовать одну и ту же библиотеку под разными целевыми платформами.
raptor
О какой бинарной совместимости вы ведете речь, если все сборки это метаданных + код на IL? Они собственно везде одинаковые.
DjoNIK
Ну для тех же Windows 8.1 и Windows Phone 8.1 совместимость по API была на неплохом уровне. Но вот на бинарном была печаль. Отсюда была подпорка в виде Shared проектов, кодовая база которых использовалась в целевых платформах.
Так при одинаковом API работы с файлами код на IL (реализация этого самого API) для той же WP8.1 может разительно отличаться от Win8.1. Ну точнее не может, а так оно и было, скорее всего.
raptor
.NET Standart — это как старый PCL, но в уже серьезном таком виде. Вы же PCL когда/если писали там код одинаковый для всех этих платформ. Я вот о чем речь веду. Конечно исключая варианты условной компиляции.
Если писать либу под .NET Standart — гарантируется, что она будет работать на всех платформах, которые поддерживают версию стандарта вами указанного.