В чем разница? between.NET Керн and.NET стандартные типы проектов библиотеки классов?

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

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

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

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

8 ответов


когда следует использовать один над другим?

решение является компромиссом между совместимостью и доступом к API.

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

используйте библиотеку .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. Однако библиотека не будет иметь доступа к некоторым частям API .NET. Например,Microsoft.NETCore.CoreCLR пакет совместим с .NET Core, но не с .NET Standard.

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

раздел фреймворков на основе пакетов здесь описывает разницу.

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

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

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

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

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

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


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

.Net Core в конечном итоге реализует .Net Standard 2 (как Xamarin и .Net Framework)

.Net Core, Xamarin и .Net Framework поэтому можно определить как блюда из .Net Standard

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

Microsoft также рекомендует использовать .NET Standard вместо Переносной Библиотеки Классов.

чтобы процитировать MSDN как авторитетный источник,.Net Стандарт предназначен для одна библиотека, чтобы управлять ими всеми. Поскольку изображения стоят тысячи слов, следующее сделает вещи очень ясными:

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

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

enter image description here

2. Что .Сетка Стандартная Библиотека позволит для вас (кросс-framework совместимость)

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

One Library to Rule them All

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

  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.
  5. .NET Standard заменит переносимые библиотеки классов (PCLs) как история инструментов для построения многоплатформенной .NET библиотеки.

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

источники: MSDN: представляем .Net Standard


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

IAnimal == .NetStandard (General)
ICat == .NetCore (Less General)
IDog == .NetFramework (Specific / oldest and has the most features)

.Net Framework и .Net Core - это две разные реализации среды выполнения .Net. И Core, и Framework (но особенно Framework) имеют разные профили, которые включают большие или меньшие (или просто разные) выборы многих API и сборок, созданных Microsoft для .Net, в зависимости от того, где они установлены и в каком профиле. Например, в универсальных приложениях Windows доступны различные API, чем в " обычном" Профиль окна. Даже в Windows у вас может быть профиль "клиент " против" полного " профиля. Кроме того, существуют другие реализации (например, Mono), которые имеют свои собственные наборы библиотек.

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

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

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

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


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

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


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

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


.NET Framework и .NET Core являются фреймворками.

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

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

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


надеюсь, это поможет понять связь между .NET Standard API surface и другими платформами .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
}
}

источник