Разница между .NET Core, Portable, Standard, Compact, UWP и PCL?

Ответ 1

Сначала отвечу на ваш второй вопрос:

У меня есть библиотека, которая нацелена на .Net 2.0,.Net 4.5 и UWP. Ориентация на UWP требовала создания нового проекта VS и связывания всех существующих файлов, что является огромной болью. Теперь кто-то говорит мне, что это не работает для PCL, и из-за этого я должен это сделать СНОВА для стандарта .Net!?)

Если я хочу написать библиотеку, которая может использоваться как можно большей аудиторией, какой из них (или нескольких) из них мне нужно использовать?

Короткий ответ: вы должны нацелиться на netstandard. Используйте самую низкую версию, в которой есть все необходимые API. Вы можете использовать инструмент Порт API для проверить существующий проект на совместимость с данная версия netstandard.

К сожалению, этот подход оставит более старые платформы, в вашем случае,.NET 2.0. Если поддержка .NET 2.0 необходима, вам понадобится отдельный проект (со связанными файлами) для сборки отдельной сборки .NET 2.0.

Подробнее...

Какая разница!?

• .Net Standard (netstandard) - это новый кросс-платформенный BCL API. Это "стандарт" в том смысле, что это просто определение API, а не реализация. Идея состоит в том, что вы можете скомпилировать вашу библиотеку (версию) этого API и работать на любой платформе, поддерживающей эту версию.
• .Net Core - вы можете думать об этом как о контрольной реализации netstandard (с несколькими дополнительными битами). Это кросс-платформенная реализация этого API. Возможно, что пользовательские интерфейсы и другие фреймворки могут опираться на него, но на данный момент его единственный надежный плацдарм выступает в качестве платформы выбора для ASP.NET Core. [Примечание: по историческим причинам ".NET Core" полностью отличается от цели netcore NuGet; когда вы находитесь в контексте NuGet, netcore означает "Windows 8/8.1/10" ].
• .Net Portable и Портативные библиотеки классов. Портативные библиотеки классов (PCL) - это подход с наименьшим общим знаменателем для предоставления кросс-платформенного API. Они охватывают широкий диапазон целевых платформ , но они неполны, а не надежны в будущем. Они по существу были заменены на netstandard.
• .Net Compact. Это совершенно другая платформа .NET с собственным уникальным API. Он полностью несовместим с любыми другими версиями Framework, PCL или netstandard; как таковой, его гораздо труднее поддерживать, чем любая другая платформа. Тем не менее, он по-прежнему используется на устройствах с ограниченными ограничениями памяти.
• Универсальная платформа Windows. Это было слияние технологий API между Windows Phone и настольным компьютером в стиле Win10, позволяющее писать приложения и библиотеки Windows Store для обеих платформ. Это по существу было заменено на netstandard.

Ответ 2

Как указано в комментариях, существует уже описание Microsoft, в котором описывается вся эта информация. Однако, по вашему мнению, кажется, что вы не полностью поняли все это. Это очень долго, поэтому здесь (надеюсь) версия tl; dr.

Мы начнем с следующей таблицы из приведенной выше ссылки, и, надеюсь, это устранит некоторые путаницы:

Краткий обзор для других попов, которые находят это позже: библиотеки .NET переполнили множество изменений и портов за последние 15 лет существования. За это время многие смартфоны стали почти такими же мощными, как некоторые настольные компьютеры, которые использовались еще в 2001 году. В этом промежутке времени были созданы подмножества .NET framework ( и быстро отказаться) для использования на разных платформах. С новым подходом Satya Nadella к тому, чтобы сделать .NET как можно более широкой платформой, все, что нужно было изменить.

Будучи 15-летней технологией, все должно быть улучшено. .NET Core работает с 2014 года как полный пересмотр архитектуры .NET. Он был переписан с нуля как новая версия языка .NET. Одной из целей Core было обеспечение межплатформенного развертывания. Будь то приложение для запуска на iPhone/Android/XBox One или на веб-сайте, который может быть размещен в IIS, или в ящике Linux,.NET Core вы охватили. Он делает это несколькими различными способами, в том числе не требуя установки .NET Framework на машине, и вместо этого будет упаковывать необходимые библиотеки с вашим решением.

В особенности с .NET Core - это радикальные изменения в ASP.NET. Старый System.Web полностью ушел и переписан как как можно более впечатляющий результат с впечатляющими результатами. Отдельные контроллеры WebApi исчезли, так как все сделано в рамках одного контроллера. Весь процесс теперь отключен, а не по умолчанию, чтобы позволить вещи, которые вы, возможно, не захотите.

Тем не менее, мы, как разработчики, захотим в конце концов перенести некоторые приложения, так как мы можем быть уверены, что код, который мы уже написали, не имел нескольких незначительных изменений имени в методах, тем самым нарушая компиляцию гигантских решений? Входит .NET Standard. Это набор API, который должен быть реализован для того, чтобы ваша платформа называла себя ".NET".

Поскольку базовая .NET Framework, с которой мы работаем много лет, хорошо известна, она использовалась в качестве основы для того, что будет включать стандарт. Тем не менее, все не включено, как бы то ни было? Таким образом, Стандарт - это только то, что обычные API-интерфейсы будут существовать между различными типами платформ .NET. В конце концов вы не будете писать код в ".NET Standard".

Xamarin (включенный в приведенную выше таблицу) был приобретенный Microsoft в 2016 году, и эта технология использовалась, чтобы помочь построить (или хотя бы вдохновить).NET Core будет кросс-платформенным. Он все еще существует как инструмент, но в тех же жилах, что и в прошлом. Согласно таблице, он будет соответствовать стандарту .NET Standard 2.0 в версии vNext. Однако целевая аудитория не изменится.

Чтобы ответить на свой вопрос, если вы хотите написать приложение с максимально возможным решением для единого развертывания, вы бы хотели использовать .NET Core. Тем не менее, если вы используете библиотеку, которая в настоящее время построена на .NET Framework 2.0 и 4.5, то вы будете зависеть от использования .NET Framework и иметь это отдельное решение UWP для этой цели.

Если он предоставляет что-то, что вы можете вызвать через вызов Web API, вы можете запустить это на своем сервере в .NET Framework и иметь единственное решение в .NET Core для развертывания для ваших конечных пользователей. Если он интегрирован в ваш код, вам, к сожалению, не повезло, пока не будет предоставлено обновление .NET Core.

Надеюсь, это устранило некоторые путаницы между различными названиями технологий.

ИЗМЕНИТЬ

После некоторого уточнения вашей конкретной ситуации я могу разобраться в этом. Вы можете несделать одно решение, которое будет нацелено на .NET Framework и .NET Core. Компиляция совершенно по-разному, с различными базовыми технологиями, так что это та же ситуация, что и попытка использовать вашу версию .NET 4.5 в решении .NET 2.0.

Тем не менее, есть tutorials, чтобы вы могли переносить свой проект на Core. По большей части просто скопируйте тела классов в ваше решение .NET Core, и большинство вещей будет работать правильно. Есть некоторые части, которые были оставлены, некоторые из которых еще не были полностью изложены на 100% (не для вашего случая, но у Entity Framework не все одинаковые функции, например). Также есть несколько вызовов, которые немного изменились.

Хорошим новичком является то, что продвижение вперед,.NET Core даст вам максимально возможный доступ..NET Framework не уходит, но он и Core будут гораздо более синхронизированы друг с другом.

Другим преимуществом .NET Core является то, что он использует итеративный подход к развертыванию, поэтому вы не будете ждать 2 года для следующего крупного обновления. Благодаря всему, что доставлено через NuGet, у вас будет намного более быстрый поворот в улучшении и новых функциях.

Ответ 3

Я предполагаю, что вы уже прочитали статью Microsoft с красивой таблицей, и теперь все ясно, как грязь. Если это так, вы находитесь в той же лодке, что и я, прежде чем я проведу большую часть дневного времени, просматривая это (и попытаюсь перенести мою тяжелую библиотеку в .NET Core, о которой я должен упомянуть, также является моим единственным .NET. Основные усилия по переносу). Ниже следует не официальная партийная линия, а мое личное резюме того, что я нашел, благодаря большому количеству чтения (и от .NET-разработчика с .NET 1.0). Я не могу ручаться за его полную точность (особенно когда речь заходит о мобильной разработке, о которой я почти полностью не осведомлен), и исправления, безусловно, приветствуются. Если есть лоты, я просто сделаю это wiki.

Я пройду через это более или менее хронологически, потому что я обнаружил, что это просто имеет смысл, если вы хотите понять, как связаны старые и новые. Скорее всего, это нужно урезать, но в настоящее время мне не хватает времени. Однако есть версия TL; DR в самом конце.

Длинная и извилистая дорога

Несмотря на свою родословную Java,.NET никогда серьезно не пыталась "писать один раз, работать где угодно". Это началось так же, как и в лагере Windows, и хотя он компилируется в байт-код и не выходит за борт с явными Windowsisms и, следовательно, теоретически очень портативен, это не то, что действительно интересовало MS. Часть .NET Framework была открытый источник на ранней стадии, и куча энтузиастов с открытым исходным кодом подняла его и побежала вместе с ним, предоставив нам Моно. Моно важно, потому что это первая альтернативная платформа и библиотека, установленная для .NET, и иллюстрирует идеи платформы и библиотеки по сравнению с инструментальной цепочкой. Mono пытается дать (более или менее) полную реализацию Common Language Runtime и ассоциированной библиотеки базового класса. Это важно: хотя Mono работает в Linux (и некоторых других Unices), это не отдельная форма, поскольку она реализует (некоторые версии) CLR + BCL. Существуют различия во времени выполнения (имена путей и т.п.), Которые имеют значение для разработчиков приложений, но для практического программирования библиотек вы можете рассматривать Mono и .NET Framework для Windows "ту же" платформу с немного другой реализацией. Я подчеркиваю это, потому что мы столкнулись с .NET-кодом, ориентированным на Windows, который не работает в среде CLR и который (по иронии или иным причинам) сложнее переносить.

Затем появились Windows Phone (несколько версий), Windows CE (несколько версий), Windows Embedded CE, Windows Toaster (хорошо, что на самом деле не существует), и некоторый вкус .NET был в основном заново изобретен каждый раз - все еще .NET, но с фундаментальными материалами из среды выполнения и/или BCL, отсутствующими или измененными. Здесь, где мы получаем .NET Compact, .NET Micro, Windows Phone (старый стиль, без отдельного имени для фреймворка) и Silverlight. Все они должны рассматриваться как отдельные платформы + библиотечные комбо, которые напоминают .NET Framework достаточно, чтобы сделать кросс-платформенную разработку возможной, но отличаться от нее достаточно, чтобы сделать ее не так просто. Поскольку отслеживание того, что было поддержано, когда стало наиболее неудобно для разделяемых библиотек, кто-то придумал идею Портативных классов классов и связанных с ними профилей (коллекция которых известна как .NET Portable Reference Assemblies).

В принципе, вы нацеливаете набор конкретных комбинаций .NET-версии, платформы (и библиотеки), и вы получите ссылочные сборки, которые имитируют эти комбинации для компиляции. Существует много разных профилей, в зависимости от того, какие вкусы вы явно хотите настроить. Это была первая попытка того, что .NET Standard сейчас использует более масштабный масштаб. В принципе, PCL теперь устарел, если вы не нацеливаетесь на что-то, что .NET Standard не пытается поддерживать..NET Standard уходит с идеей создания нескольких разных профилей, что хорошо, за счет сокращения некоторых вещей, которые ваша библиотека может направить раньше, что плохо. Есть ресурсы в Интернете, чтобы помочь с переходом с PCL на .NET Standard. Если вы сейчас смотрите на переносимый код, вы не хотите фокусироваться на PCL, если вы действительно не хотите поддерживать некоторые довольно маргинальные платформы (без обид, предназначенных для людей, которые все еще разрабатывают для них).

Универсальная платформа Windowsявляется, как следует из названия, платформой. В частности, это платформа .NET, поддерживаемая приложениями Windows Store (как на рабочем столе, так и на телефоне). Это не больше, не меньше. Он лучше всего считается естественным преемником Silverlight в том, что он поддерживает изолированную среду для настольных компьютеров и мобильных устройств. Несмотря на название, это не универсальная платформа, и вы не хотите, чтобы весь ваш код был нацелен. Это платформа, которую вы можете захотеть включить для своего кода, и она уникальна тем, что она является единственной платформой, которую я знаю о том, что у нее две версии времени в одной и той же версии. Приходите прямо!

.NET Native не упоминался в исходном сообщении, но часто появляется в этих обсуждениях, потому что он тоже новый, как и .NET Core, и звучит очень сексуально, потому что он напрямую компилирует .NET to машина код (пораньше сбор, нет JIT сбор). Это не полная новая платформа, а новая среда выполнения для приложений UWP (и только тех), когда они скомпилированы в режиме Release. В режиме отладки они используют CoreCLR (среда выполнения .NET Core). Вам не нужно будет думать об этом очень тяжело, если вы действительно не хотите создавать приложение UWP, потому что там всевозможные интересные вещи происходят с отражением в .NET Native, которому требуется отдельное внимание от разработчика приложений.

И теперь мы приходим к .NET Core!.NET Core начал работать как "ASP.NET Core", но люди быстро поняли, что он может быть намного больше..NET Core - это новая библиотека времени исполнения (CoreCLR) + с явной кросс-платформенной поддержкой (как в кросс-OS). В отличие от комбайна CLR + BCL, где есть версия Windows и версия Unix в виде Mono,.NET Core является одной кодовой базой для всех платформ (с обычными хрустящими битами для конкретной платформы, чтобы, конечно, поддерживать пушистый переносной слой выше), Что еще более смущает людей, так это то, что .NET Core также является именем нового типа toolchain/project для поддержки создания приложений .NET Core, где до того, как мы получили только MSBuild. Это было обусловлено отсутствием Visual Studio для Linux, но MS уже отходит от этого "пусть он прост и JSON" подходит и перемещается вернемся к одному универсальному формату как для .NET Framework, так и для .NET Core (и это будет MSBuild, потому что там гораздо больше покоится).

.NET Core по большей части очень совместим с .NET Framework. В результате, если ваше приложение .NET Core действительно работает на платформе .NET Framework (в Windows), оно может загружать сборки, предназначенные для .NET Framework, а не только для .NET Core. Это важный источник путаницы и неуправляемого кода: в то время как вы можете создавать и загружать эти сборки, они сделают ваш код не переносимым..NET Core сам по себе не остановит вас от этого; Стандарт .NET(подходит прямо вверх) будет, если вы правильно разместите свои объявления.

Со мной до сих пор? Хорошо, потому что теперь мы готовы отказаться от .NET Standard на вашей ничего не подозревающей голове..NET Standard не является платформой (в том смысле, что вы не можете загрузить и установить ее на компьютере), это не библиотека (но есть пакеты для ее поддержки в целях сборки), это профиль. Это попытка стандартизировать поверхность библиотеки в широком диапазоне вещей, которые мы только что обсуждали. Идея заключается в том, что если ваш код нацелен на .NET Standard XY, вам нужно всего лишь переключить свои инструменты сборки на "пожалуйста, дайте мне .NET Standard XY", и когда вы создадите сборку, вы можете быть уверены, что она будет использоваться для всех платформ покрытый XY Ура! Мир снова прост!

Ну, пока это не так. Проблема в том, что .NET Core в настоящее время находится в тяжелом развитии, что означает, что многие вещи отсутствуют или различны - даже весьма фундаментальные вещи, которые могут быть естественным образом представлены в вашей базе данных .NET Framework, например, маркировка ваших исключений Serializable и давая им отдельный конструктор для десериализации, чтобы они хорошо работали через AppDomain s. В .NET Core нет AppDomain, поэтому нет сериализации, поэтому эти конструкторы не будут компилироваться. Даже самый атрибут Serializable отсутствует в более старых версиях CoreCLR. Если ваш проект MSBuild использует настраиваемые цели, это слишком плохо, то инструментальная цепочка .NET Core не поддерживает эту информацию на данный момент (возможно, в будущем, когда MSBuild снова). Вы можете переписать, конечно, но не использовать повторно. Поэтому, пока вы можете настроить таргетинг на .NET Standard, вам может потребоваться два отдельных проекта и/или некоторые условные компиляции, чтобы получить сборку .NET Standard для двух разных платформ. Если вам повезет (или может немного скомпрометировать), ваша библиотека достаточно проста, что может быть достаточно для ее создания с помощью .NET Core. Не ошибитесь: все еще есть несколько платформ .NET, и у них все еще есть свои отличия,.NET Standard просто пытается упростить перенос. Пока он ограничен, но уже делает более чистую работу, чем PCL.

Подводя итог:.NET Core и .NET Framework (и все их маленькие кузены и племянники) являются отдельными платформами как концептуально, так и путем реализации..NET Standard - это профиль таргетинга, который упрощает усилия, необходимые для кода между ними (но еще не делает его полностью прозрачным). PCL является предшественником стандарта, который можно игнорировать, если вы прогрессивные.

TL; DR начинается здесь (но все еще TL)

Чтобы наконец ответить на ваш вопрос, что вы должны сделать, если вы современный разработчик библиотеки и хотите настроить таргетинг "как можно больше аудитории"? Ну, в первую очередь, вы должны сделать это меньше, если это возможно. На каких платформах вы будете явно поддерживать и тестировать? Вы действительно хотите настроить .NET Compact на свой XBox 360? Windows Phone 7? Серебряный свет восемь лет назад? Если вы это сделаете, вы, вероятно, не сможете обойти PCL, но у большинства из нас будет роскошь быть в состоянии избежать этого. Если нет: очередь отдельной сборки PCL, если ваш профиль ничего не соответствует стандарту .NET.

Является ли ваша библиотека очень простой (без отражения, нет async/await, нет зависимостей от больших фреймворков, таких как WCF)? Тогда вы можете настроить таргетинг на сечение .NET 2.0 и самую низкую версию .NET Standard, в которой вам нужны зависимости от структуры. Не обманывайте себя, более низкие версии .NET Standard действительно разочаровывают в том, что они предлагают, но вам нужно заплатить определенную цену за переносимость. Нет поддержки инструментальных средств для построения как для .NET 2.0, так и для версии .NET Standard. Вы должны построить его дважды и проверить его "везде", хотя поперечное сечение означает, что вы можете быть разумно уверены, что он будет работать, если он скомпилируется. Полученная библиотека будет поддерживать каждую платформу .NET, которая может загружать сборки ванов .NET 2.0 (это почти все из них, но не Micro и Compact) и .NET Core, и все без переходов в платформу. Поздравляю, мир никогда не видел что-то настолько портативное!

Будет ли ваша библиотека использовать отражение? Тогда вы, вероятно, не сможете обойти переписывание кода, чтобы он скомпилировался для .NET Core, потому что API-интерфейс изменился некоторое время назади ваш код, возможно, еще не догнал (поскольку не было необходимости, если вы только нацеливались только на полную фреймворк). В этом случае вы захотите использовать целевую версию .NET Framework до версии 4.5, так как это версия .NET Framework, совместимая с этими изменениями. Здесь вы начинаете получать поддержку инструментальных средств: вы можете настроить .NET Standard 1.1, который охватывает подмножество .NET 4.5. Если вы обнаружите, что этого подмножества недостаточно, вам снова придется прибегать к созданию дважды: для полной .NET Framework и для .NET Core. Причина в том, что .NET Core 1.0 поддерживает "больше", чем .NET Framework 4.5, но пока еще нет версии .NET Framework, вы можете настроить таргетинг на Core Core (это будет "vNext" ). Поэтому, если вы не хотите ограничивать себя только .NET Core, но также хотите поддержать тех из нас, которые все еще строят простые старые настольные приложения 4.5 и .NET Standard 1.1 недостаточно для вас, вам придется разделить. Неправильное дело - указать значение 1.1, а затем импортировать Framework 4.5 только пакеты/сборки, так как это принесет вам худшее из обоих миров с точки зрения переносимости!

Будет ли ваша библиотека нуждаться в некоторых улучшениях/расширениях более 4.5, которые были представлены в версии 4.5.1 или новее, или в пакетах, которые доступны только для более высоких версий .NET Standard? Затем настройте соответствующую стандартную версию .NET Standard. Обратите внимание, что Microsoft больше не поддерживает официально 4.x ниже 4.5.2. Это не означает, что вы не должны настраивать таргетинг на эти версии (как можно ниже), но это означает, что у вас есть аргумент для использования не что иное, как .NET Standard 1.2, и если вы можете потребовать 4.6, не менее 1,5. Это не является обременительным для потребителей (если вы готовы и можете установить 4.6, вы почти наверняка захотите и сможете установить 4.6.2) и облегчит вашу жизнь. В зависимости от вашего кода вы можете избавиться только от сборки .NET Core, но вы, вероятно, этого не хотите, потому что цепочка сборки .NET Core еще не стабильна и вернется к MSBuild (как упоминалось ранее). Отсутствие смысла в том, чтобы отбросить все ваши файлы проектов для JSON только для возврата назад!

Использует ли ваша библиотека какую-либо условную компиляцию? Опасайтесь, с помощью ключевого инструмента .NET Core вы получите различные предопределенные символы. Они лишний супер раздражает, потому что они настаивают (скажем) провести различие между 4.5, 4.5.1 и 4.5.2, что является болью, если вы хотите охватить "4.5 и выше". Ничто из тщательной сборки не может справиться, но, тем не менее, вам нужно принять во внимание.

Я не рассматриваю мобильные сборки здесь (Xamarin и более старые версии телефонов), потому что, ну, я знаю очень мало об этом! Я полагаю, что эта история почти такая же, как и для .NET Core и .NET Framework, поскольку это здание работает только для простых библиотек и библиотек, где вам не нужно заботиться о обратной совместимости и, по крайней мере, два строят иначе, но, как я уже сказал в начале, исправления приветствуются.