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

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

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

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

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

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

Решение - это компромисс между совместимостью и доступом к 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.

Библиотека классов .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

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

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

.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.

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

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

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

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

Надеюсь, что это поможет понять взаимосвязь между поверхностью .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
}
}

Источник

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

Стандарт .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 использует его как зависимость.

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

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

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

В проекте, который вам нужно смешать между .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/

.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

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