違い - uwp.net standard

いつ一方をもう一方の上に使用すべきですか？

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

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

ライブラリがアクセスできる.NET APIの表面積を増やしたい場合は.NET Coreライブラリを使用します。ライブラリと互換性のある.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 Core、.NET Framework、Mono / Xamarinなど、.NET Standard準拠のランタイムで実行されます。 一方、.NET Coreをターゲットとするライブラリは、.NET Coreランタイムでのみ実行できます。

API Surface Area：.NET Standardライブラリには NETStandard.Library すべてが付属していますが、.NET Coreライブラリには Microsoft.NETCore.App すべてが付属してい Microsoft.NETCore.App 。 後者には、約20個の追加ライブラリが含まれています。そのうちのいくつかは、.NET標準ライブラリ（ System.Threading.Thread など）に手動で追加できるものと、.NET標準と互換性のないもの（ Microsoft.NETCore.CoreCLR など） ）。

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

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

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

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

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

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

.NET Frameworkと.NET Coreを使用して実行可能なプロジェクト（コンソールアプリケーション、ASP.NETアプリケーションなど）を作成できますが、.NET Standardは使用できません。

.NET Standardでは、スタンドアロンで実行できないクラスライブラリプロジェクトのみを作成でき、別の.NET Coreまたは.NET Framework実行可能プロジェクトから参照する必要があります。

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

ライブラリの作成中に、ターゲットとして.Net Standard 2.0を使用して、作成されたライブラリが.Net Core、Monoなどの異なるバージョンの.Net Frameworkと互換性を持つようにすることができます。

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

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

違いを説明する別の方法は、実世界の例を使用することです。ほとんどの人間は既存のツールとフレームワーク（Xamarin、Unityなど）を使用して仕事をするからです。

そのため、.NET Frameworkにはすべての.NETツールを使用できますが、Windowsアプリケーション（UWP、Winforms、ASP.NETなど）のみを対象とすることができます。 .NET Frameworkはクローズドソースであるため、あまり対処する必要はありません。

.NET Coreを使用すると、ツールは少なくなりますが、メインのデスクトッププラットフォーム（Windows、Linux、Mac）をターゲットにできます。 これは、Asp.netをLinuxでホストできるようになったため（ASP.NETコアアプリケーションでは特に便利です（ホスティング料金が安い））。 現在、.NET Coreはオープンソースであるため、他のプラットフォーム用のライブラリを開発することは技術的に可能です。 しかし、それをサポートするフレームワークがないので、それは良い考えだとは思いません。

.NET Standardを使用すると、ツールはさらに少なくなりますが、すべて/ほとんどのプラットフォームをターゲットにできます。 Xamarinのおかげでモバイルをターゲットにでき、Mono / Unityのおかげでゲームコンソールもターゲットにできます。

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

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

• アプリケーションのモデルを処理する.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アプリケーション。

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

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

したがって、.NET標準ライブラリ（クライアントAPIとViewModels）の両方を再利用でき、WPF、Xamarin、IOSアプリケーションのロジックなしでビューを作成できるため、アプリケーションのクライアント側に大きな利点があることがわかります。

これが 、.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
}
}

Source

.Net Framework と .Net Core は、.Netランタイムの2つの異なる実装です。 CoreとFramework（特にFramework）の両方には、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は、SysAdminチームがWindows上のASP.Netから哲学的またはコスト上の理由でLinux上の.Net CoreのASP.Netに移行したいが、開発チームが.Netに対して引き続き作業したい場合にも役立ちます。 Windows上のVisual Studioのフレームワーク。