.NET Standard Library – адекватный стандарт?

    Всякий раз, когда в текущем процессе появляются отклонения, надо задать следующие вопросы: «Это случилось потому, что у нас не было стандарта? Это случилось потому, что мы не следовали стандарту? Это случилось потому, что стандарт не был адекватным?»
    Масааки Имаи (автор концепции Кайдзен)

    image

    Кроссплатформенность — одно из основных требований для приложения на рынке. Большая часть современных языков программирования кроссплатформенны, однако, почти на всех языках разработчик сталкивается с проблемой совместимости его ПО с той или иной системой. Приходится компилировать свой проект под конкретную операционную систему или вести разработку проекта под среду исполнения интерпретируемого языка.

    Среда исполнения .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 и конечными платформами.

    image

    Выделить кроссплатформенное ядро приложения стало гораздо проще. Достаточно, чтобы ядро собиралось под 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 с следующей ячейкой в той же строке.

    Примеры:

    1. Если библиотека удовлетворяет спецификациям .NET Standard 1.3, то она может быть использована только на платформах: .NET Framework 4.6 (и более новыми), .NET Core, Universal Windows Platform 10 (UWP) и Mono/Xamarin.
    2. Если библиотека пишется под Standard 1.3, то в ней можно использовать другие библиотеки, которые написаны с использованием версий Standard: 1.0, 1.1, 1.2, 1.3.

    Понимание .NET Standard Library


    .NET Standard Library можно представить в виде абстрактных множеств, каждое следующие будет содержать предыдущее и добавлять, что-то своё, покрывая больше кода платформ .NET. Соответственно, их размер будет увеличиваться по мере увеличения номера версии.

    image

    C каждой новой версией функционал ядра приложения будет расти, однако, многие возможности «полноценных» платформ будут не доступны. Посмотрим на изображения других множеств: .NET Framework, .NET Core, Mono/Xamarin:

    imageimageimage

    .NET Standard одной и той же версии покрывает идентичное множество кода этих платформ. И находится целиком внутри их пересечения. Ядро приложения будет находится внутри центрального круга. Само приложение лучше разделить на три части для реализации поддержки других платформ. Таким образом, готовый продукт будет работать сразу на трёх платформах и на нескольких операционных системах.

    imageimage

    Плюсы использования .NET Standard Library:


    • Кроссплатформенность, несколько платформ .NET, несколько операционных систем.
    • Поддержка кода — проект будет проще поддерживать после релиза, добавляя в него новый функционал без портирования.
    • Гарантия работы — очередная библиотека из Nuget под .NET Standard точно будет работать на нескольких операционных системах.

    Минусы использования .NET Standard Library:


    • Ограничения по функционалу из коробки — .NET Standard продолжает развиваться.
    • Сложности с переносом под .NET Standard уже существующих проектов.

    Заключение


    .NET Standard Library является хорошей заменой неудобной библиотеки Portable Class Library. Standard Library гораздо лучше в плане кроссплатформенности. Теперь можно без больших проблем выделить кроссплатформенное ядро приложения или разработать кроссплатформенную библиотеку, удовлетворяющие спецификациям .NET Standard. Затем написать нужные интерфейсы под необходимые операционные системы и получить готовый продукт.
    Share post

    Similar posts

    Comments 37

      +1
      Эта совместимость гарантируется на бинарном уровне или на уровне API?
        0
        Похоже, глупость спросил. Ибо если не бинарная совместимость, то как мы сможем использовать одну и ту же библиотеку под разными целевыми платформами.
          +1
          О какой бинарной совместимости вы ведете речь, если все сборки это метаданных + код на IL? Они собственно везде одинаковые.
            0
            Ну для тех же Windows 8.1 и Windows Phone 8.1 совместимость по API была на неплохом уровне. Но вот на бинарном была печаль. Отсюда была подпорка в виде Shared проектов, кодовая база которых использовалась в целевых платформах.

            код на IL

            Так при одинаковом API работы с файлами код на IL (реализация этого самого API) для той же WP8.1 может разительно отличаться от Win8.1. Ну точнее не может, а так оно и было, скорее всего.
              0
              .NET Standart — это как старый PCL, но в уже серьезном таком виде. Вы же PCL когда/если писали там код одинаковый для всех этих платформ. Я вот о чем речь веду. Конечно исключая варианты условной компиляции.

              Если писать либу под .NET Standart — гарантируется, что она будет работать на всех платформах, которые поддерживают версию стандарта вами указанного.

        0

        Что такое платформа win? Которая версии 8.0 и 8.1. И чем она отличатся от .Net Framework ?

          0
          Это та что была предшественницей UWP.
            0

            WinRT

            0
            Есть подозрение, что это WinRT вызовы которые стали доступны для вызова в Windows 8/8.1, например Windows.Storage
              0
              А где это реально указывается? Это проекты типа '.Net Standart` теперь можно создавать или что?
                0
                В файле project.json. Да, по умолчанию в .net core все class library создаются под netstandart1.6.
                  0
                  Я наверно чего-то не понимаю, но project.json же только для dotNet_Core? А остальные?
                    0
                    Да с введением всех этих стандартов путаница усилилась. И надо время, что бы разобраться теперь во всем что MS и сообщество сделали за эти пару лет. Особенно вся хрень с переименованиями платформ, стандартов, металиб и т.п.

                    Вы можете создать проект .netCore указать, что весь код совместим с netstandart1.6 и собрать его. Потом, сборку — вы можете использовать во всех проектах, которые будут совместимы с netstandart1.6 в том числе и c .NET Framework.
                      0
                      Внутри project.json указываются таргет фреймворки, так что он не только для dotNet Core.
                      +1
                      По последним новостям, MS отказывается от project.json и возвращается к csproj и msbuild. https://blogs.msdn.microsoft.com/dotnet/2016/10/19/net-core-tooling-in-visual-studio-15/
                        0
                        Что их так колбасит-то. То туда, то сюда. Причём по разным проектам же видно.
                          0
                          Что бы не плодить лишние сущности был вариант переносить весь туллинг для всех видов проектов на project.json или использовать и развить уже существующую систему. Они выбрали второй путь.
                          В существующей системе существуют несколько проблемы, которых нет в project.json.
                          1) В .csproj указываются все файлы включаемые в проект. Это увеличивает вероятность конфликтов при мерже изменений и вообще зашумлет файл
                          2) Информация о включенных пакетах заносится в два места в package.json и в .csproj
                          3) Нет поддержки сross-targeting для различных версий фреймворка

                          Выбранный путь дает плюшки для всех видом проектов, и старых и новых, не выкидывая, а улучшая старый туллинг. В бонус пойдет работа через dotnet cli для всех видов проектов, и автоматическая миграция с project.json.
                            0
                            1) В .csproj указываются все файлы включаемые в проект. Это увеличивает вероятность конфликтов при мерже изменений и вообще зашумлет файл

                            Сейчас уже нет, в *.csproj поддерживается wildcard: <Compile Include="**\*.cs" />.

                    0
                    Почему бы просто не портировать .net framework для macos/Linux?!
                      +3
                      Что вы подразумеваете под «портировать»? Как я понимаю, собственно, .NET Core и есть попытка запилить как можно более широкую кроссплатформенную часть.
                        0
                        MS говорили, что портировать почти невозможно, поэтому просто написали все заново раздробив на мелкие кусочки так, что бы больше не приходилось ставить на машину отдельно фреймворк, чтобы запустить приложение. Так .NET Core появился.
                        +4

                        Чета много написано, а суть .NET Standard простая. До него в .NET Standard явно указывались совместимые платформы. Вышла новая платформа или версия — пересобирай либу, публикуй новую версию пакета


                        После появления .NET Standard в PCL указывается не версия платформы, а версия стандарта. И проекты под все совместимые с этой версией стандарта платформы могут либу добавить.


                        Ну и вторая причина — так как стандарт развивается раньше конкретных платформ, то платформы будут стремиться соответствовать стандарту. В идеале (где-то в районе .NET Std3)это будет один и тот же код на всех платформах.

                          +3
                          Microsoft добавляет новую платформу .NET Standard Library. [..] .NET Standard Library — формальный набор спецификаций общих интерфейсов

                          И всё-таки, .NET Standard Library — это платформа, библиотека (library) или набор спецификаций?
                            0

                            Стандарт библиотек платформы.

                              0
                              Де-факто .Net Standard это куча классов, все методы и свойства которых бросают NotImplementedException(). Соответственно компилятору этого достаточно. А в рантайме используются реальные классы с реализацией.
                              +6

                              Самое понятное объяснение что такое .NET Standard я видел у David Fowler вот тут

                                +2
                                Если кто пропустил, то есть анонс .NET Standard 2.0 на Хабре. Из особенностей — был откат изменений, поэтому новый стандарт совместим с .NET Framework 4.6.1, а не 4.6.3.
                                  +2
                                  .NET выглядит лучшим, на мой взгляд, решением для разработки кроссплатформенного ПО


                                  Обоснуйте.
                                    +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.

                                    Сорри, если кого обидел случайно, просто личные наблюдения :)

                                      0
                                      Кроссплатформенный серверсайд вполне можно писать на стандартных плюсах, например.

                                      Но это тоже сугубо ИМХО и личный опыт.
                                        0
                                        Только вот реально времени это займет больше. И дальнейшая поддержка дороже выйдет. Все-таки, что не говори, а С# и Java в плане скорости разработки, особенно под энтерпрайз, ушли существенно дальше чем C++.
                                          0
                                          У меня есть небольшой опыт разработки на C# и большой опыт разработки на плюсах. И я, признаться, не очень понимаю, почему специалист по C++ и специалист по C# должны писать с существенно разной скоростью, особенно если бизнес-логика достаточно серьёзная.

                                          Ну и на C++ производительный код писать легче, да.

                                          Стоимость программиста будет, вероятно, выше, да, но я как программист не буду сильно протестовать.
                                            0
                                            Простое отсутствие стандартной библиотеки в C++ уже усложняет разработку. Да есть сторонние, куча их, несовместимых между собой. Самая боль — строки.

                                            Да, понятно, что на проекте выбирается определённый набор библиотек под стандартные задачи, но если разработчик меняется, приходит новый, то тут дополнительные расходы на знакомство с текущим набором библиотек под простейшие задачи, в худшем случае разработчику придётся учиться работать с новой библиотекой. А если где-то в процессе пойдёт сбой, так и вообще свою библиотеку подтянет, с которой уже работал.

                                            Синтаксический сахар для асинхронной работы: в C# можно писать асинхронный код, будто он последовательный. Ну и куча таких мелочей.
                                              0
                                              Вообще-то хотя бы просто формально STL — стандартная библиотека. Даже со строками.

                                              Boost можно, кстати, считать вполне себе стандартом де-факто для квалифицированного разработчика на C++.

                                              Ну и async/await в C++17 уже завезли. И не в любом сервер-сайде это нужно, кстати, мягко скажем.
                                                0
                                                Ничего не имею против C++, но в большом бэкенд проекте я бы отдал предпочтение type safe(хотя бы почти) языку — проще найти людей, люди стоят дешевле, меньше способов выстрелить себе в ногу(особенно при наличии junior разработчиков). Плюс в том же C# всегда можно уйти в unsafe, если сильно припекло :D Ну и тот же CoreRT пилят.
                                                C++ 17 вроде как — «nearly feature-complete».

                                                Хорошо хоть memory model завезли ;)
                                                  0
                                                  Плюс в том же C# всегда можно уйти в unsafe,

                                                  В том числе и в плюсы
                                                  0
                                                  Я сейчас конечно не бекенд ковыряю, но реально кроссплатформенную тулу на C++ которая работает на всех десктоп и мобильный осях. И это ад. Во многом, конечно, из-за того, что код тянется с 90х. Там куча задефайненных флагов под разные платформы. И там собственная реализация строк. Хорошо, если во всех нужных вам зависимостях будет использоваться STL, а если нет? Зоопарк зависимостей.

                                                  Кстати, на iOS эта штука ходит в интернет через Obj-C, вероятно потому что все стандартизировано и универсально.

                                                  >Ну и async/await в C++17 уже завезли.
                                                  Даже в C#, где компилятор можно считать один, прошло 3-4 года, пока нормально обновились большинство библиотек с поддержкой этой фичи, и стало комфортно пользоваться ей.

                                                  Вспомнить менеджеры зависимостей ещё. (да, я знаю, есть альтернативы для плюсов, но стандарта нет даже де-факто).

                                                  Это все мелочи, но каждая потенциально отъедает время. За счёт этого у Java и C# скорость разработки и выше. Понятно, что это во многом зависит и от разработчиков и от внутренних процессов. Но средний результат будет такой.

                                    Only users with full accounts can post comments. Log in, please.