.NET Coreプロジェクトタイプと.NET Standard Class Libraryプロジェクトタイプの違いは何ですか？

Visual Studioには、少なくとも3つの異なるタイプのクラスライブラリを作成できます。

• クラスライブラリ（.NET Framework）
• クラスライブラリ（.NET標準）
• クラスライブラリ（.NET Core）

最初のものは私たちが長年使用してきたものですが、.NET Standardおよび.NET Coreクラスライブラリタイプをいつ使用するかが、私がずっと混乱していた主な点です。私は最近、さまざまなフレームワークバージョンをマルチターゲットにしてユニットテストプロジェクトを作成しようとしたときに、これに噛まれました。

それでは、クラスライブラリ（.NET Standard）とクラスライブラリ（.NET Core）の違いは何ですか、なぜ両方が存在するのか、そしていつどちらを使用する必要があるのでしょうか。

いつどちらを使用すればよいですか？

この決定は、互換性とAPIアクセスの間のトレードオフです。

ライブラリと互換性のあるアプリの数を増やしたい場合や、ライブラリがアクセスできる.NET APIの表面積を減らしても問題がない場合は、.NET標準ライブラリを使用します。

ライブラリがアクセスできる.NET APIの表面積を増やしたい場合は、.NET Coreライブラリを使用します。ライブラリとの互換性を.NET Coreアプリのみに許可してもかまいません。

たとえば、.NET Standard 1.3を対象とするライブラリは、.NET Framework 4.6、.NET Core 1.0、Universal Windows Platform 10.0、および.NET Standard 1.3をサポートするその他のプラットフォームを対象とするアプリと互換性があります。ただし、ライブラリは.NET APIの一部にアクセスできません。たとえば、 Microsoft.NETCore.CoreCLRパッケージは.NET Coreと互換性がありますが、.NET Standardとは互換性がありません。

クラスライブラリ（.NET Standard）とクラスライブラリ（.NET Core）の違いは何ですか？

パッケージベースのフレームワークのセクションでは、違いについて説明しています。

互換性：.NET Standardをターゲットとするライブラリは、.NET Core、.NET Framework、Mono / Xamarinなどの.NET Standard準拠のランタイムで実行されます。一方、.NET Coreをターゲットとするライブラリは、.NET Coreランタイムでのみ実行できます。

API Surface Area：.NET Standardライブラリにはすべてが含まれてNETStandard.Libraryいますが、.NET Coreライブラリにはすべてが含まれていMicrosoft.NETCore.Appます。後者には約20の追加ライブラリが含まれており、そのうちの一部は.NET標準ライブラリ（などSystem.Threading.Thread）に手動で追加でき、一部は.NET標準と互換性がありません（などMicrosoft.NETCore.CoreCLR）。

また、.NET Coreライブラリはランタイムを指定し、アプリケーションモデルに付属しています。たとえば、単体テストのクラスライブラリを実行可能にすることは重要です。

なぜ両方が存在するのですか？

しばらくライブラリを無視して、.NET標準が存在する理由は移植性のためです。.NETプラットフォームが実装することに同意する一連のAPIを定義します。.NET標準を実装するプラットフォームは、その.NET標準を対象とするライブラリと互換性があります。これらの互換性のあるプラットフォームの1つは.NET Coreです。

ライブラリに戻ると、.NET標準ライブラリテンプレートは複数のランタイムで実行するために存在します（APIの表面積を犠牲にして）。逆に、.NET Coreライブラリテンプレートは、（互換性を犠牲にして）より多くのAPIサーフェスにアクセスし、実行可能ファイルを構築するプラットフォームを指定するために存在します。

これは、どの.NET標準がどの.NET実装をサポートするか、および使用可能なAPI表面積を示すインタラクティブなマトリックスです。

A .NETコアクラスライブラリ上に構築され、.NETの標準。.NET Frameworkに移植可能なライブラリを実装する場合は、。.NET CoreおよびXamarin、.NET標準ライブラリを選択

.NET Coreは最終的に.NET Standard 2を実装します（Xamarinや.NET Frameworkも同様）

.NETコア、Xamarinと.NET Frameworkは、したがって、として識別することができる風味の.NET標準

コード共有と再利用のためにアプリケーションを将来にわたって保証するには、.NET標準ライブラリを実装する必要があります。

マイクロソフトでは、Portable Class Librariesではなく.NET Standardを使用することもお勧めします。

MSDNを信頼できる情報源として引用するために、.NET Standardはそれらすべてを支配する1つのライブラリとなることを目的としています。写真は千の言葉に値するので、次のようにすると非常に明確になります。

1.現在のアプリケーションシナリオ（断片化）

私たちのほとんどと同様に、あなたはおそらく以下の状況にあります：（.NET Framework、Xamarin、そして今は.NET Core風味のアプリケーション）

2. .NET標準ライブラリによって何が可能になるか（フレームワークの互換性）

.NET標準ライブラリを実装すると、これらすべての異なるフレーバー間でコードを共有できます。

せっかちな人のために：

1. .NET Standardは、デスクトップアプリケーション、モバイルアプリとゲーム、クラウドサービスなど、必要な環境全体で期待され、愛されているすべてのAPIを提供することで、すべてのプラットフォームにわたる.NET開発者のコ​​ード共有問題を解決します。
2. .NET標準であるAPIのセットすべての.NETプラットフォームを実装する必要があります。これは、.NETプラットフォーム統一と防止将来の断片化を。
3. .NET Standard 2.0は、.NET Frameworkによって実装されます。NET Core、Xamarin。以下のために.NETのコア、これは要求されている既存のAPIの多くを追加します。
4. .NET Standard 2.0には、.NET Frameworkバイナリの互換性シムが含まれており、.NET Standardライブラリから参照できるライブラリのセットが大幅に増えています。
5. .NET Standard は、マルチプラットフォーム.NETライブラリを構築するためのツールストーリーとして、ポータブルクラスライブラリ（PCL）に置き換わります。

実行する.NETプラットフォームに基づいて、ターゲットにできる.NET Standardの最高バージョンを理解するのに役立つ表については、こちらをご覧ください。

出典：MSDN：.NET Standardの紹介

したがって、短い答えは次のようになります。

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

.NETと.NET Coreは、.NETランタイムの2つの異なる実装です。コアとフレームワーク（特にフレームワーク）には、Microsoftが.NET用に作成した多くのAPIとアセンブリの大きいまたは小さい（または単純に異なる）選択を含む異なるプロファイルがあり、それらがインストールされている場所とプロファイルによって異なります。

たとえば、ユニバーサルWindowsアプリでは、「通常の」Windowsプロファイルとは異なるAPIがいくつか利用できます。Windowsでも、「クライアント」プロファイルと「フル」プロファイルがある場合があります。さらに、独自のライブラリセットを持つ他の実装（Monoなど）もあります。

.NET Standardは、APIライブラリとアセンブリのセットが利用可能でなければならない仕様です。.NET Standard 1.0用に作成されたアプリは、ライブラリの.NET Standard 1.0コレクションのサポートを宣伝するFramework、Core、Monoなどの任意のバージョンでコンパイルおよび実行できる必要があります。同様のことが.NET Standard 1.1、1.5、1.6、2.0などにも当てはまります。ランタイムがプログラムのターゲットとなるStandardのバージョンをサポートしている限り、プログラムはそこで実行されます。

標準のバージョンを対象とするプロジェクトは、標準のそのリビジョンに含まれていない機能を利用できません。これは、他のアセンブリや他のベンダーによって公開されているAPI（つまり、NuGetのアイテム）に依存できないことを意味するものではありません。ただし、依存関係には、使用しているバージョンの.NET Standardのサポートも含まれている必要があります。.NET Standardは急速に進化していますが、それでもまだ十分に新しく、いくつかの小さなランタイムプロファイルを十分に考慮しているため、この制限は息苦しく感じることがあります。（1年半後のメモ：これは変更され始めており、最近の.NET Standardバージョンははるかに優れており、フル機能を備えています）。

一方、Standard を対象とするアプリは、理論的にはCore、Framework、Monoなどで実行できるため、より多くの展開状況で使用できるはずです。幅広いディストリビューションを求めるクラスライブラリプロジェクトの場合、これは魅力的な約束です。主に内部目的で使用されるクラスライブラリプロジェクトの場合、それほど心配する必要はありません。

.NET Standardは、システム管理者チームが哲学的またはコスト上の理由でWindowsのASP.NETからLinuxの.NET CoreのASP.NETに移行したいが、開発チームがに反対したい場合にも役立ちます。 Windows上のVisual StudioのNE​​T Framework。

.NET Frameworkと.NET Coreはどちらもフレームワークです。

.NET Standardは標準（つまり、仕様）です。

.NET Frameworkと.NET Coreでは実行可能プロジェクト（コンソールアプリケーションやASP.NETアプリケーションなど）を作成できますが、.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
}
}

ソース

違いを説明するもう1つの方法は、現実の例を使用することです。私たちの多くの人間は、既存のツールとフレームワーク（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を使用してWebクライアントをターゲットにすることも可能です（ただし、どちらも現在は実験的なものです）。

実際のアプリケーションでは、それらすべてを使用する必要がある場合があります。たとえば、私は次のアーキテクチャを持つPOSアプリケーションを開発しました。

サーバーとクライアントの両方を共有：

• アプリケーションのモデルを処理する.NET標準ライブラリ。
• クライアントから送信されたデータの検証を処理する.NET標準ライブラリ。

これは.NET標準ライブラリなので、他のどのプロジェクト（クライアントとサーバー）でも使用できます。

同じ検証がサーバーとクライアントに適用されていることを確認できるので、.NET標準ライブラリで検証を行うことの素晴らしい利点もあります。サーバーは必須ですが、クライアントはオプションであり、トラフィックを減らすのに役立ちます。

サーバー側（Web API）：

• すべてのデータベース接続を処理する.NET標準（コアの場合もあります）ライブラリ。

• Rest APIを処理し、データベースライブラリを利用する.NET Coreプロジェクト。

これは.NET Coreで開発されているため、アプリケーションをLinuxサーバーでホストできます。

クライアント側（WPF + Xamarin.Forms Android / IOSを備えたMVVM）：

• クライアントAPI接続を処理する.NET標準ライブラリ。

• ViewModelsロジックを処理する.NET標準ライブラリ。すべてのビューで使用されます。

• WindowsアプリケーションのWPFビューを処理する.NET Framework WPFアプリケーション。更新：WPFアプリケーションは現在.NETコアにすることができますが、現在はWindowsでのみ機能します。AvaloniaUIは、他のデスクトッププラットフォーム用のデスクトップGUIアプリケーションを作成するための優れた代替手段です。

• Xamarinフォームビューを処理する.NET標準ライブラリ。

• Xamarin AndroidおよびXamarin IOSプロジェクト。

.NET Standardライブラリ（クライアント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で実行可能なアプリケーションを作成できます（現時点ではコンソールのみですが、GUIはありません）。したがって、.NET Core = .NET Standard +デスクトップ固有のもの。

また、UWPはそれを使用し、新しいASP.NET Coreは依存関係としても使用します。

.NET標準は、主にコード共有を改善し、各.NET実装で利用できるAPIの一貫性を高めるために存在します。

ライブラリを作成している間、ターゲットを.NET Standard 2.0にすることができるため、作成されたライブラリは.NET Core、Monoなどの.NET Frameworkのさまざまなバージョンと互換性があります。

上記の回答は、ネットコア、ネット標準、ネットフレームワークの違いについて最もよく理解しているので、これを選択するときの経験を共有したいと思います。

.NET Framework、.NET Core、.NET Standardを混在させる必要があるプロジェクト。たとえば、.NET Core 1.0でシステムを構築する時点では、.netコアでホストするウィンドウサービスはサポートされていません。

次の理由は、.NET Coreをサポートしないアクティブレポートを使用していたことです。したがって、.NET Core（asp.net core）とWindows Service and Reporting（.NET Framework）の両方に使用できるインフラストラクチャライブラリを構築したいと考えています。そのため、この種のライブラリに.NET Standardを選択しました。。

結論：

• インフラストラクチャライブラリおよび共有共通の.NET標準。このlibは、.NET Frameworkおよび.NET Coreから参照できます。
• Active ReportやWindow Servicesなどのサポートされていないテクノロジ用の.NET Framework（現在は.NET 3.0でサポートされています）。
• もちろん.NET Core for ASP.NET Core。

マイクロソフトは.NET 5を発表しました：https : //devblogs.microsoft.com/dotnet/introducing-net-5/

.NET Framework Windowsフォーム、ASP.NETおよびWPFアプリケーションは、.NET Frameworkライブラリを使用して開発する必要があります

.NET標準 Xamarin、IO、およびMAC OSxアプリケーションは、.NET標準ライブラリを使用して開発する必要があります

.NET Core
Universal Windows Platform（UWP）およびLinuxアプリケーションは、.NET Coreライブラリを使用して開発する必要があります。APIはC ++で実装されており、C ++、VB.NET、C＃、F＃、JavaScript言語を使用できます。

.Netコアクラスライブラリは、.Net標準に基づいて構築されています。.Net Framework、.Net Core、Xamarinに移植可能なライブラリを実装する場合は、.Net標準ライブラリを選択してください