В чем разница между типами проектов .NET Core и .NET Standard Class Library?

815

В Visual Studio можно создать как минимум 3 различных типа библиотек классов:

  • Библиотека классов (.NET Framework)
  • Библиотека классов (.NET Standard)
  • Библиотека классов (.NET Core)

В то время как первое - это то, что мы использовали в течение многих лет, основная путаница, с которой я столкнулся, - это когда используются типы библиотек классов .NET Standard и .NET Core. Недавно меня это укусило, когда я пытался нацелить разные версии фреймворка и создавал проект модульного тестирования .

Итак, в чем разница между библиотекой классов (.NET Standard) и библиотекой классов (.NET Core) , почему они существуют, и когда мы должны использовать одно над другим?

Gigi
источник
10
Вы пропустили одно: библиотека классов (переносная). Core == Framework, .NET Standard == переносимый.
Ганс
4
Был также один из Xamarin, но эти другие не добавляют никакой ценности к вопросу :)
Gigi
7
Ну, они делают. Основная идея заключается в том, что они отказались от портативного подхода, он слишком сильно пострадал от n! Проблема с пути слишком много профилей. Итак, теперь у вас есть 7 стандартов на выбор. Большинство из них на самом деле не являются переносимыми на данный момент :). NETCore не закончен, возможно, потребуется еще два года на клип, который они собираются.
Ганс
12
ОП сказал "как минимум 3 разных типа". Пост был точным.
Дэн Фридман
1
Меня смутило название Core, которое не является основным подмножеством ни Standard, ни Framework. Также мы регулярно видим ASP, связанный с .Net Core. Это тоже очень сбивает с толку ...
Алексис Паутрот

Ответы:

612

Когда мы должны использовать один над другим?

Решение - это компромисс между совместимостью и доступом к API.

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

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

Например, библиотека, ориентированная на .NET Standard 1.3, будет совместима с приложениями, ориентированными на .NET Framework 4.6, .NET Core 1.0, универсальную платформу Windows 10.0 и любую другую платформу, поддерживающую .NET Standard 1.3. Однако библиотека не будет иметь доступа к некоторым частям .NET API. Например, Microsoft.NETCore.CoreCLR пакет совместим с .NET Core, но не с .NET Standard.

В чем разница между библиотекой классов (.NET Standard) и библиотекой классов (.NET Core)?

Раздел Основанные на пакетах разделы описывает разницу.

Совместимость. Библиотеки, ориентированные на .NET Standard, будут работать в любой среде, совместимой с .NET Standard, например .NET Core, .NET Framework, Mono / Xamarin. С другой стороны, библиотеки, предназначенные для .NET Core, могут работать только в среде выполнения .NET Core.

Площадь поверхности API: библиотеки .NET Standard поставляются со всем, в NETStandard.Libraryто время как библиотеки .NET Core поставляются со всем Microsoft.NETCore.App. Последняя включает в себя около 20 дополнительных библиотек, некоторые из которых мы можем добавить вручную в нашу библиотеку .NET Standard (например, System.Threading.Thread), а некоторые из них не совместимы с .NET Standard (например,Microsoft.NETCore.CoreCLR ).

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

Почему оба существуют?

На мгновение игнорируя библиотеки, причина существования .NET Standard - в переносимости; он определяет набор API, которые платформы .NET соглашаются реализовать. Любая платформа, реализующая стандарт .NET, совместима с библиотеками, ориентированными на этот стандарт .NET. Одной из таких совместимых платформ является .NET Core.

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

Вот интерактивная матрица, которая показывает, какой стандарт .NET поддерживает какие реализации .NET и сколько доступно площади поверхности API.

Шон Луттин
источник
2
Очень хороший ответ Тем не менее, дополнительный вопрос (относится к этому вопросу : почему модель приложения необходима для запуска модульных тестов? Этого никогда не было в прошлом, когда мы использовали неработающие библиотеки классов для хранения коллекций модульных тестов.
Gigi
3
Я обновил свой ответ на связанный вопрос. TL; DR; В прошлом библиотеки классов предназначались для полной структуры, которая включает модель приложения.
Шон Луттин,
Вы забыли рассказать о библиотеке классов (.NET Framework), совместима ли она с .NET Standard и .NET Core?
Томас
8
Эта диаграмма действительно помогла мне получить это.
jpaugh
1
@BerBar Первоначальный вопрос был о разнице между .NET Standard и .NET Core. Вот почему я пропустил кроссплатформенные детали, потому что кроссплатформенность не является разницей между Core и Standard. Я намеренно сохранил свой ответ на первоначальный вопрос.
Шон Луттин
396

Библиотека классов .NET ядро построено на .NET Standard . Если вы хотите реализовать библиотеку , которая является портативной к .NET Framework ,. .NET Core и Xamarin , выберите стандартную библиотеку .NET

.NET Core в конечном итоге будет реализовывать .NET Standard 2 (как и Xamarin и .NET Framework )

.NET Ядро , Xamarin и .NET Framework , следовательно, могут быть идентифицированы как ароматизаторы в .NET Standard

Чтобы обеспечить будущее совместное использование и повторное использование ваших приложений, вы бы предпочли использовать библиотеки .NET Standard.

Microsoft также рекомендует использовать .NET Standard вместо Portable Class Libraries .

Чтобы цитировать MSDN как авторитетный источник, предполагается , что .NET Standard - это одна библиотека, управляющая ими всеми . Поскольку картинки стоят тысячи слов, следующее будет очень понятно:

1. Ваш текущий сценарий приложения (фрагментированный)

Как и большинство из нас, вы, вероятно, находитесь в ситуации ниже: (.NET Framework, Xamarin и теперь .NET Core).

Введите описание изображения здесь

2. Что стандартная библиотека .NET обеспечит для вас (кросс-фреймворковая совместимость)

Реализация стандартной библиотеки .NET позволяет совместно использовать код для всех этих различных разновидностей:

Одна библиотека, чтобы управлять ими всеми

Для нетерпеливых:

  1. .NET Standard решает проблему совместного использования кода для разработчиков .NET на всех платформах, предоставляя все API, которые вы ожидаете и любите, в нужных вам средах: настольных приложениях, мобильных приложениях и играх и облачных сервисах:
  2. .NET Standard - это набор API, которые должны быть реализованы на всех платформах .NET . Это объединяет платформы .NET и предотвращает будущую фрагментацию .
  3. .NET Standard 2.0 будет реализован .NET Framework . NET Core и Xamarin . Для .NET Core это добавит многие существующие API, которые были запрошены.
  4. .NET Standard 2.0 включает в себя прокладку совместимости для .NET Framework двоичных файлов , что значительно расширяет набор библиотек, на которые можно ссылаться из своих библиотек .NET Standard.
  5. .NET Standard заменит Portable Class Libraries (PCL) в качестве инструмента для создания многоплатформенных библиотек .NET.

Для таблицы, которая поможет понять, какая самая высокая версия .NET Standard, на которую вы можете ориентироваться, в зависимости от того, на каких платформах .NET вы собираетесь работать, перейдите сюда .

Источники: MSDN: внедрение стандарта .NET

user919426
источник
2
ASP.NET Core немного неуместен в этой графике, поскольку его можно использовать с полной версией .NET Framework, а не только с .NET Core, поскольку он фактически нацелен на .NET Standard.
NEME
2
Но вы можете создать приложение ASP.NET Core с полной версией .NET Framework - ASP.NET Core действительно принадлежит к тому же уровню, что и .NET Standard. Это не ограничивается только .NET Core.
NEME
1
@Neme Во-первых, да. .Net Core может включать библиотеки .Net Framework, но теряет кроссплатформенное повторное использование (только для Windows - не * nix или OSX, или повторное использование в Xamarin). Ситуация, которая была учтена, учитывая, что многие имеют и хотят повторно использовать существующие библиотеки, написанные в полной .Net Framework, без интереса к межплатформенным преимуществам (на уровне ОС и уровне модели приложений) ... Если вы все еще чувствуете, что я неправильно, возможно, вы можете поспорить с Microsoft, которая является автором этих изображений ... :-)
user919426
3
Я не говорю о комбинировании .NET Core и .NET Framework. Я хочу сказать, что ASP.NET Core не зависит от .NET Core, несмотря на название. Он написан как библиотека, предназначенная для .NET Standard, поэтому вы можете использовать ее везде, где вы можете использовать .NET Standard. Да, они ошиблись в этом образе.
NEME
2
@OgrishMan Вы не можете создать исполняемый файл в .Net Standard . Это может быть только библиотека классов, на которую может ссылаться другой исполняемый код. У него нет времени выполнения .
user919426
91

Таким образом, краткий ответ будет:

IAnimal == .NetStandard (General)
ICat == .NetCore (Less General)
IDog == .NetFramework (Specific / oldest and has the most features)
Джо
источник
26
@ Joe.wang, как я вижу, плохо, что портит отношения между .NET Core и .NET Framework. Если .NET Core - это птица, то .NET Framework не может быть орлом (возможно, кошка больше подходит).
Лекс Ли
8
@LexLi прав, это мутит воду. .NET Framework не является подтипом .NET Core.
Эрик
6
это может показаться немного причудливым, но не
острым
3
Оригинальный комментарий @Joe звучал более точно. отредактированный ответ Сообщества сделал это запутанным
Нандун
7
У собак больше особенностей, чем у кошек? Нет :)
hrzafer
71

.NET и .NET Core - две разные реализации среды выполнения .NET. И Core, и Framework (но особенно Framework) имеют разные профили, которые включают большие или меньшие (или просто разные) варианты множества API и сборок, созданных Microsoft для .NET, в зависимости от того, где они установлены и в каком профиле.

Например, в универсальных приложениях Windows есть несколько других API, чем в «обычном» профиле Windows. Даже в Windows у вас может быть профиль «Клиент» против профиля «Полный». Кроме того, есть и другие реализации (например, Mono ), которые имеют свои собственные наборы библиотек.

.NET Standard - это спецификация, для которой должны быть доступны наборы API-библиотек и сборок. Приложение, написанное для .NET Standard 1.0, должно быть способным компилироваться и работать с любой версией Framework, Core, Mono и т. Д., Которая рекламирует поддержку коллекции библиотек .NET Standard 1.0. Подобное верно и для .NET Standard 1.1, 1.5, 1.6, 2.0 и т. Д. Если среда выполнения поддерживает версию Standard, предназначенную для вашей программы, ваша программа должна работать там.

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

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

.NET Standard также может быть полезен в ситуациях, когда команда системного администратора хочет перейти с ASP.NET для Windows на ASP.NET для .NET Core для Linux по философским соображениям или по соображениям стоимости, но команда разработчиков хочет продолжать работать против. NET Framework в Visual Studio для Windows.

Джоэл Коухорн
источник
1
Хотя это хороший обзор того, что такое .NET Core и .NET Standard, этот ответ не дает ответа на вопрос о библиотеках классов, нацеленных на каждую из них.
Гиги
6
Если это ваша цель, вопрос должен быть закрыт как «неясно, что вы спрашиваете», поскольку всегда будет слишком много ситуативных особенностей, которые играют в среде данного человека, чтобы мы когда-либо просто говорили вам, что делать или «Слишком широко», если вы спрашиваете об общем случае. Все, что мы можем сделать здесь, это дать вам информацию о продуктах, чтобы вы могли быть проинформированы для принятия собственного решения.
Джоэл Кохорн
Это явно не тот случай, так как другой точно ответил на вопрос. Мой вопрос был о библиотеках классов. Ваш ответ был о рамках.
Гиги,
29

.NET Framework и .NET Core - это фреймворки.

.NET Standard - это стандарт (другими словами, спецификация).

Вы можете создать исполняемый проект (например, консольное приложение или приложение ASP.NET) с помощью .NET Framework и .NET Core, но не с .NET Standard.

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

б сторона
источник
20

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

namespace Analogy
{
  // .NET Standard

interface INetStandard10
{
    void Primitives();
    void Reflection();
    void Tasks();
    void Xml();
    void Collections();
    void Linq();
}

interface INetStandard11 : INetStandard10
{
    void ConcurrentCollections();
    void LinqParallel();
    void Compression();
    void HttpClient();
}

interface INetStandard12 : INetStandard11
{
    void ThreadingTimer();
}

interface INetStandard13 : INetStandard12
{
    //.NET Standard 1.3 specific APIs
}

// And so on ...


// .NET Framework 

interface INetFramework45 : INetStandard11
{
    void FileSystem();
    void Console();
    void ThreadPool();
    void Crypto();
    void WebSockets();
    void Process();
    void Drawing();
    void SystemWeb();
    void WPF();
    void WindowsForms();
    void WCF();
}

interface INetFramework451 : INetFramework45, INetStandard12
{
    // .NET Framework 4.5.1 specific APIs
}

interface INetFramework452 : INetFramework451, INetStandard12
{
    // .NET Framework 4.5.2 specific APIs
}

interface INetFramework46 : INetFramework452, INetStandard13
{
    // .NET Framework 4.6 specific APIs
}

interface INetFramework461 : INetFramework46, INetStandard14
{
    // .NET Framework 4.6.1 specific APIs
}

interface INetFramework462 : INetFramework461, INetStandard15
{
    // .NET Framework 4.6.2 specific APIs
}

// .NET Core
interface INetCoreApp10 : INetStandard15
{
    // TODO: .NET Core 1.0 specific APIs
}
// Windows Universal Platform
interface IWindowsUniversalPlatform : INetStandard13
{
    void GPS();
    void Xaml();
}

// Xamarin 
interface IXamarinIOS : INetStandard15
{
    void AppleAPIs();
}

interface IXamarinAndroid : INetStandard15
{
    void GoogleAPIs();
}    
// Future platform

interface ISomeFuturePlatform : INetStandard13
{
    // A future platform chooses to implement a specific .NET Standard version.
    // All libraries that target that version are instantly compatible with this new
    // platform
}
}

Источник

Махбубур Рахман
источник
17

Другой способ объяснить разницу может быть на реальных примерах, так как большинство из нас, смертных, будут использовать существующие инструменты и структуры (Xamarin, Unity и т. Д.) Для выполнения этой работы.

Итак, с .NET Framework у вас есть все инструменты .NET для работы, но вы можете ориентироваться только на приложения Windows (UWP, Winforms, ASP.NET и т. Д.). Поскольку .NET Framework является закрытым исходным кодом, с этим ничего не поделаешь.

С .NET Core у вас меньше инструментов, но вы можете ориентироваться на основные настольные платформы (Windows, Linux, Mac). Это особенно полезно в приложениях ASP.NET Core, поскольку теперь вы можете размещать Asp.net в Linux (более дешевые цены на хостинг). Теперь, так как .NET Core был открытым исходным кодом, технически возможно разрабатывать библиотеки для других платформ. Но поскольку нет фреймворков, поддерживающих его, я не думаю, что это хорошая идея.

С .NET Standard у вас еще меньше инструментов, но вы можете ориентироваться на все / большинство платформ. Вы можете настроить таргетинг на мобильные устройства благодаря Xamarin, и вы даже можете настроить таргетинг на игровые консоли благодаря Mono / Unity. Обновление: также возможно предназначаться для веб-клиентов с платформой UNO и Blazor (хотя оба являются экспериментальными прямо сейчас).

В реальных приложениях вам может понадобиться использовать их все. Например, я разработал приложение для точек продаж, имеющее следующую архитектуру:

Совместное использование как сервера, так и клиента:

  • Стандартная библиотека .NET, которая обрабатывает модели моего приложения.
  • Стандартная библиотека .NET, которая обрабатывает проверку данных, отправляемых клиентами.

Поскольку это стандартная библиотека .NET, ее можно использовать в любом другом проекте (клиент и сервер).

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

Сторона сервера (веб-API):

  • Библиотека .NET Standard (может быть и Core), которая обрабатывает все соединения с базой данных.

  • Проект .NET Core, который обрабатывает Rest API и использует библиотеку базы данных.

Поскольку это разработано в .NET Core, я могу разместить приложение на сервере Linux.

Клиентская часть (MVVM с WPF + Xamarin.Forms для Android / IOS):

  • Стандартная библиотека .NET, которая обрабатывает клиентское соединение API.

  • Стандартная библиотека .NET, которая обрабатывает логику ViewModels. Используется во всех видах.

  • Приложение .NET Framework WPF, которое обрабатывает представления WPF для приложения Windows. Обновление: приложения WPF теперь могут быть ядром .NET, хотя в настоящее время они работают только на Windows. AvaloniaUI - хорошая альтернатива для создания приложений с графическим интерфейсом для других настольных платформ.

  • Стандартная библиотека .NET, которая обрабатывает представления форм Xamarin.

  • Проект Xamarin для Android и Xamarin IOS.

Итак, вы можете видеть, что здесь есть большое преимущество в клиентской части приложения, поскольку я могу повторно использовать обе стандартные библиотеки .NET (Client API и ViewModels) и просто создавать представления без логики для приложений WPF, Xamarin и IOS.

Дев Кевин
источник
2
Я думаю, что это лучший ответ, поскольку он включает в себя реальный мир.
J Weezy
12

Стандарт .NET: думайте об этом как о большой стандартной библиотеке. При использовании этого в качестве зависимости вы можете создавать только библиотеки (.DLL), но не исполняемые файлы. Библиотека, созданная на основе стандарта .NET, может быть добавлена ​​в проект Xamarin.Android, Xamarin.iOS, .NET Core для Windows / OS X / Linux.

.NET Core: воспринимайте это как продолжение старой платформы .NET, просто она с открытым исходным кодом, а некоторые вещи еще не реализованы, а другие устарели. Он расширяет стандарт .NET дополнительными функциями, но работает только на настольных компьютерах . При добавлении этого в качестве зависимости вы можете запускать приложения в Windows, Linux и OS X. (Хотя консоль только на данный момент, без графического интерфейса). Так. .NET Core = .NET Standard + настольный материал.

Также UWP использует его, и новое ядро ASP.NET использует его как зависимость.

Peter Mortensen
источник
8

.NET Standard существует главным образом для улучшения совместного использования кода и повышения доступности API-интерфейсов в каждой реализации .NET.

При создании библиотек мы можем иметь цель как .NET Standard 2.0, чтобы созданная библиотека была совместима с различными версиями .NET Framework, включая .NET Core, Mono и т. Д.

ARP
источник
2

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

В проекте, который вам нужно смешать между .NET Framework, .NET Core и .NET Standard. Например, в то время, когда мы собираем систему с .NET Core 1.0, нет поддержки оконных служб с .net core.

Следующая причина в том, что мы использовали Active Report, который не поддерживает .NET Core. Поэтому мы хотим создать инфраструктурную библиотеку, которая может использоваться как для .NET Core (ядро asp.net), так и для службы Windows и отчетности (.NET Framework) -> Вот почему мы выбрали .NET Standard для такой библиотеки. Выбор стандарта .NET означает, что вам необходимо тщательно рассмотреть каждый класс в библиотеке, который должен быть простым и перекрестным .NET (ядро, фреймворк, стандарт).

Вывод:

  • Стандарт .NET для инфраструктуры библиотеки и общего доступа. На эту библиотеку могут ссылаться .NET Framework и .NET Core.
  • .NET Framework для неподдерживаемых технологий, таких как Active Report, Window Services (теперь он поддерживает .NET 3.0).
  • .NET Core для ASP.NET Core, конечно.

Microsoft только что анонсировала .NET 5: https://devblogs.microsoft.com/dotnet/introduction-net-5/

toannm
источник
@Gigi Пожалуйста, внимательно прочитайте мой ответ, я сказал, что это было, когда .NET Core в версии 1.0, и в этом случае мы хотим разработать решение, объединяющее как ядро ​​.NET, так и среду .NET. ASP.NET Core поддерживает .NET Framework начиная с версии 2.0. Мой ответ - это история, когда вам приходится иметь дело с несколькими версиями .NET. Поэтому я не могу понять, почему у вас есть отрицательное мнение, когда вы не правильно понимаете ситуацию.
Toannm
Спасибо за ваш ответ - я прочитал ваш ответ и прочитал ту часть, в которой вы ссылались на .NET Core 1.0. И все же я не воспринял это как обязательное условие для интерпретации ваших выводов, что в противном случае могло бы ввести в заблуждение людей, читающих с текущей версией. Кроме того, похоже, что мой комментарий был взломан полицией Stack Overflow, к какому позору я привык на этом сайте.
Гиги
0

.NET Framework Windows Form, ASP.NET и приложение WPF должны быть разработаны с использованием библиотеки .NET Framework

.NET Standard Приложения Xamarin, IO и MAC OSx должны быть разработаны с использованием библиотеки .NET Standard

.NET Core
Универсальная платформа Windows (UWP) и приложение Linux должны разрабатываться с использованием библиотеки .NET Core. API реализован на C ++, и вы можете использовать языки C ++, VB.NET, C #, F # и Javascript .NET

Фабио Панзирони
источник
0

Базовая библиотека классов .Net построена на основе стандарта .Net. Если вы хотите реализовать библиотеку, переносимую на .Net Framework, .Net Core и Xamarin, выберите .Net Standard Library.

Омер Озкан
источник
Ваш ответ не полностью связан с вопросом. пожалуйста,
Avid Programmer