У чому різниця між проектами .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, Universal Windows Platform 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 Core.

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

Крім того, бібліотеки .NET Core задають час виконання та поставляються з моделлю програми. Наприклад, це важливо зробити так, щоб зробити бібліотеки модульних тестових класів запущеними.

Чому обидва існують?

На деякий час ігноруючи бібліотеки, причина існування .NET Standard полягає в мобільності; він визначає набір API, які платформи .NET погоджуються реалізувати. Будь-яка платформа, яка реалізує .NET Standard, сумісна з бібліотеками, націленими на .NET Standard. Однією з таких сумісних платформ є .NET Core.

Повертаючись до бібліотек, існують шаблони бібліотек .NET Standard, які працюють у декількох режимах виконання (за рахунок поверхні поверхні API). Зрозуміло, існують шаблони бібліотек .NET Core для доступу до більшої площі API (за рахунок сумісності) та для визначення платформи, на якій можна створити виконуваний файл.

Ось інтерактивна матриця, яка показує, який .NET Standard підтримує які .NET реалізації (-и) та кількість поверхні API доступна.

Бібліотека класів .NET ядро побудовано на .NET Standard . Якщо ви хочете реалізувати бібліотеку , яка є портативною до .NET Framework ,. .NET Core та Xamarin , виберіть .NET Standard Library

.NET Core в кінцевому рахунку реалізує .NET Standard 2 (як і Xamarin і .NET Framework) )

.NET Ядро , Xamarin і .NET Framework , отже, можуть бути ідентифіковані як аромати з .NET Standard

Щоб у майбутньому перевірити свої програми для спільного використання та повторного використання коду, ви краще впровадите бібліотеки .NET Standard.

Microsoft також рекомендує використовувати .NET Standard замість бібліотек портативних класів .

Якщо цитувати 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 замінить бібліотеки портативних класів (PCL) як історія інструментарію для створення багатоплатформних бібліотек .NET.

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

Джерела: MSDN: Представлення .NET Standard

Отже, коротка відповідь буде:

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, залежно від того, де вони встановлені та в якому профілі.

Наприклад, у програмах Universal 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, орієнтованої на вашу програму, ваша програма повинна працювати там.

Проект, орієнтований на версію Standard, не зможе використовувати функції, які не включені в цю редакцію стандарту. Це не означає, що ви не можете приймати залежності від інших збірок або API-файлів, опублікованих іншими постачальниками (тобто: позиціями на NuGet). Але це означає, що будь-які залежність, яку ви приймаєте, також повинна містити підтримку вашої версії .NET Standard. .NET Standard розвивається швидко, але він все ще досить новий і достатньо піклується про деякі з менших профілів виконання, щоб це обмеження могло бути задушливим. (Зверніть увагу на півтора року пізніше: це починає змінюватися, і останні версії .NET Standard набагато приємніші та повнофункціональніші).

З іншого боку, додаток, орієнтований на 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. Оновлення: Також можна націлити на веб-клієнтів за допомогою платформи ООН та Blazor (хоча обидва зараз начебто експериментальні).

У реальному додатку вам може знадобитися використовувати їх усі. Наприклад, я розробив додаток для продажу, який мав таку архітектуру:

Спільний доступ до сервера та клієнта:

• Бібліотека .NET Standard, яка обробляє Моделі моєї програми.
• Бібліотека .NET Standard, яка обробляє перевірку даних, що надсилаються клієнтами.

Оскільки це бібліотека .NET Standard, її можна використовувати в будь-якому іншому проекті (клієнт і сервер).

Також приємна перевага наявності перевірки на стандартній бібліотеці .NET, оскільки я можу бути впевнений, що однакова перевірка застосовується на сервері та клієнті. Сервер є обов'язковим, тоді як клієнт - необов’язковий і корисний для зменшення трафіку.

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

• Стандартна бібліотека .NET (може бути і Core), яка обробляє всі підключення до бази даних.

• Проект .NET Core, який обробляє API відпочинку та використовує бібліотеку баз даних.

Оскільки це розроблено в .NET Core, я можу розмістити додаток на сервері Linux.

Сторона клієнта (MVVM з WPF + Xamarin.Forms Android / IOS):

• Бібліотека .NET Standard, яка обробляє з'єднання API клієнта.

• Бібліотека .NET Standard, яка обробляє логіку ViewModels. Використовується у всіх переглядах.

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

• Стандартна бібліотека .NET, яка обробляє подання Xamarin Forms.

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

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

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

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

Також UWP використовує його, а новий ASP.NET Core також використовує його як залежність.

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

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

Наведені вище відповіді можуть описувати найкраще розуміння різниці між чистим ядром, чистим стандартом та чистим фреймворком, тому я просто хочу поділитися своїм досвідом, обираючи це над цим.

У проекті, який потрібно поєднувати між .NET Framework, .NET Core та .NET Standard. Наприклад, у той час, коли ми будуємо систему за допомогою .NET Core 1.0, немає підтримки Window Services, що розміщує ядро ​​.net.

Наступна причина - ми використовували Active Report, який не підтримує .NET Core. Таким чином, ми хочемо створити інфраструктурну бібліотеку, яка може використовуватися як для .NET Core (ядра asp.net), так і для служби Windows та звітування (.NET Framework) -> Тому ми вибрали .NET Standard для такого типу бібліотеки. Вибір стандарту .NET означає, що вам потрібно ретельно розглянути, що кожен клас у бібліотеці повинен бути простим і перехрещеним .NET (core, frame, standard).

Висновок:

• .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/introducing-net-5/

Форма .NET Framework Windows, додаток ASP.NET і WPF повинні бути розроблені за допомогою бібліотеки .NET Framework

Додаток .NET Standard Xamarin, IO та MAC OSx потрібно посвятити за допомогою бібліотеки .NET Standard

.NET Core
Universal Windows Platform (UWP) та додатки Linux повинні бути розроблені за допомогою бібліотеки .NET Core. API реалізований на C ++, і ви можете використовувати C ++, VB.NET, C #, F # та Javascript languages.NET

Бібліотека базового класу .Net побудована за стандартом .Net. Якщо ви хочете реалізувати бібліотеку, яка переноситься на .Net Framework, .Net Core та Xamarin, виберіть .Net Standard Library