Qual è la differenza tra i tipi di progetto .NET Core e .NET Standard Class Library?

In Visual Studio, esistono almeno 3 diversi tipi di libreria di classi che è possibile creare:

• Libreria di classi (.NET Framework)
• Libreria di classi (.NET Standard)
• Libreria di classi (.NET Core)

Mentre il primo è quello che stiamo usando da anni, un grande punto di confusione che ho avuto è quando usare i tipi di libreria di classi .NET Standard e .NET Core. Sono stato morso da questo di recente quando ho tentato di scegliere come target diverse versioni di framework e di creare un progetto di unit test .

Quindi, qual è la differenza tra Class Library (.NET Standard) e Class Library (.NET Core) , perché esistono entrambe e quando dovremmo usarne una rispetto all'altra?

Quando dovremmo usare l'uno sull'altro?

La decisione è un compromesso tra compatibilità e accesso API.

Utilizzare una libreria .NET Standard quando si desidera aumentare il numero di app che saranno compatibili con la propria libreria e si è d'accordo con una riduzione dell'area della API .NET alla quale è possibile accedere alla propria libreria.

Utilizzare una libreria .NET Core quando si desidera aumentare la superficie dell'API .NET alla quale la libreria può accedere e si è d'accordo nel consentire che solo le app .NET Core siano compatibili con la propria libreria.

Ad esempio, una libreria destinata a .NET Standard 1.3 sarà compatibile con le app destinate a .NET Framework 4.6, .NET Core 1.0, Universal Windows Platform 10.0 e qualsiasi altra piattaforma che supporti .NET Standard 1.3. Tuttavia, la libreria non avrà accesso ad alcune parti dell'API .NET. Ad esempio, il Microsoft.NETCore.CoreCLRpacchetto è compatibile con .NET Core ma non con .NET Standard.

Qual è la differenza tra Class Library (.NET Standard) e Class Library (.NET Core)?

La sezione Framework basati su pacchetti descrive la differenza.

Compatibilità: le librerie destinate a .NET Standard verranno eseguite su qualsiasi runtime conforme a .NET Standard, come .NET Core, .NET Framework, Mono / Xamarin. D'altro canto, le librerie destinate a .NET Core possono essere eseguite solo sul runtime .NET Core.

Superficie dell'API: le librerie .NET standard includono tutto, NETStandard.Librarymentre le librerie .NET Core sono dotate di tutto Microsoft.NETCore.App. Quest'ultimo include circa 20 librerie aggiuntive, alcune delle quali possiamo aggiungere manualmente alla nostra libreria .NET Standard (come System.Threading.Thread) e alcune non sono compatibili con .NET Standard (come Microsoft.NETCore.CoreCLR).

Inoltre, le librerie .NET Core specificano un runtime e vengono fornite con un modello di applicazione. È importante, ad esempio, rendere eseguibili le librerie di classi di unit test.

Perché entrambi esistono?

Ignorando le librerie per un momento, la ragione per cui esiste .NET Standard è per la portabilità; definisce una serie di API che le piattaforme .NET accettano di implementare. Qualsiasi piattaforma che implementa uno standard .NET è compatibile con le librerie destinate a tale standard .NET. Una di queste piattaforme compatibili è .NET Core.

Tornando alle librerie, i modelli di libreria .NET Standard esistono per essere eseguiti su più runtime (a scapito della superficie dell'API). Al contrario, i modelli di libreria .NET Core esistono per accedere a più aree API (a spese della compatibilità) e per specificare una piattaforma sulla quale costruire un eseguibile.

Ecco una matrice interattiva che mostra quale .NET Standard supporta quali implementazioni .NET e quanta superficie API è disponibile.

Una libreria di classi .NET Core si basa sullo standard .NET . Se si desidera implementare una libreria che è portatile per il .NET Framework ,. .NET Core e Xamarin , scegli una libreria standard .NET

.NET Core implementerà infine .NET Standard 2 (come Xamarin e .NET Framework )

.NET Core , Xamarin e .NET Framework possono quindi essere identificati come versioni di .NET Standard

Per rendere future le applicazioni per la condivisione e il riutilizzo del codice, è preferibile implementare le librerie .NET Standard.

Microsoft consiglia inoltre di utilizzare .NET Standard anziché le librerie di classi portatili .

Per citare MSDN come fonte autorevole, .NET Standard vuole essere una libreria per dominarli tutti . Dato che le immagini valgono più di mille parole, ciò che segue renderà le cose molto chiare:

1. Il tuo scenario di applicazione attuale (frammentato)

Come la maggior parte di noi, probabilmente ci si trova nella seguente situazione: (applicazioni .NET Framework, Xamarin e ora .NET Core)

2. Cosa abiliterà .NET Library per te (compatibilità tra framework)

L'implementazione di una libreria .NET standard consente la condivisione del codice in tutti questi diversi gusti:

Per l'impaziente:

1. .NET Standard risolve il problema di condivisione del codice per gli sviluppatori .NET su tutte le piattaforme portando tutte le API che ti aspetti e ami negli ambienti di cui hai bisogno: applicazioni desktop, app e giochi per dispositivi mobili e servizi cloud:
2. .NET Standard è un insieme di API che tutte le piattaforme .NET devono implementare . Ciò unifica le piattaforme .NET e impedisce la frammentazione futura .
3. NET standard 2.0 sarà attuato da .NET Framework ,. NET Core e Xamarin . Per .NET Core , questo aggiungerà molte delle API esistenti che sono state richieste.
4. .NET Standard 2.0 include uno shim di compatibilità per i binari di .NET Framework , aumentando in modo significativo il set di librerie a cui è possibile fare riferimento dalle librerie .NET Standard.
5. .NET Standard sostituirà Portable Class Libraries (PCLs) come la storia degli strumenti per la creazione di librerie .NET multipiattaforma.

Per una tabella che aiuti a capire quale sia la versione più alta di .NET Standard che puoi scegliere come target, in base alle piattaforme .NET su cui intendi eseguire, vai qui .

Fonti: MSDN: Presentazione di .NET Standard

Quindi la risposta breve sarebbe:

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

.NET e .NET Core sono due diverse implementazioni del runtime .NET. Sia Core che Framework (ma soprattutto Framework) hanno profili diversi che includono selezioni più grandi o più piccole (o semplicemente diverse) delle numerose API e assiemi creati da Microsoft per .NET, a seconda di dove sono installati e in quale profilo.

Ad esempio, ci sono alcune API diverse disponibili nelle app di Windows universali rispetto al profilo "normale" di Windows. Anche su Windows, potresti avere il profilo "Client" rispetto al profilo "Full". Inoltre, e ci sono altre implementazioni (come Mono ) che hanno i propri set di librerie.

.NET Standard è una specifica per la quale devono essere disponibili set di librerie e assembly API. Un'app scritta per .NET Standard 1.0 dovrebbe essere in grado di compilare ed eseguire con qualsiasi versione di Framework, Core, Mono, ecc., Che pubblicizza il supporto per la raccolta di librerie .NET Standard 1.0. Simile è vero per .NET Standard 1.1, 1.5, 1.6, 2.0, ecc. Fintanto che il runtime fornisce supporto per la versione di Standard targetizzata dal tuo programma, il tuo programma dovrebbe essere eseguito lì.

Un progetto destinato a una versione di Standard non sarà in grado di utilizzare funzionalità che non sono incluse in quella revisione dello standard. Ciò non significa che non è possibile accettare dipendenze da altri assembly o API pubblicati da altri fornitori (ad esempio: articoli su NuGet). Ciò significa che tutte le dipendenze che prendi devono includere anche il supporto per la tua versione di .NET Standard. .NET Standard si sta evolvendo rapidamente, ma è ancora abbastanza nuovo e si preoccupa abbastanza di alcuni dei profili di runtime più piccoli, che questa limitazione può sembrare soffocante. (Nota un anno e mezzo dopo: questo sta iniziando a cambiare e le recenti versioni di .NET Standard sono molto più belle e più complete).

D'altra parte, un'app destinata a Standard dovrebbe essere in grado di essere utilizzata in più situazioni di distribuzione, dal momento che in teoria può funzionare con Core, Framework, Mono, ecc. Per un progetto di biblioteca di classe in cerca di ampia distribuzione, questa è una promessa interessante . Per un progetto di biblioteca di classe utilizzato principalmente per scopi interni, potrebbe non essere un problema.

.NET Standard può essere utile anche in situazioni in cui il team dell'amministratore di sistema desidera passare da ASP.NET su Windows ad ASP.NET per .NET Core su Linux per motivi filosofici o di costo, ma il team di sviluppo vuole continuare a lavorare contro. NET Framework in Visual Studio su Windows.

.NET Framework e .NET Core sono entrambi framework.

.NET Standard è uno standard (in altre parole, una specifica).

È possibile creare un progetto eseguibile (come un'applicazione console o un'applicazione ASP.NET) con .NET Framework e .NET Core, ma non con .NET Standard.

Con .NET Standard è possibile creare solo un progetto di libreria di classi che non può essere eseguito autonomamente e deve essere referenziato da un altro progetto eseguibile .NET Core o .NET Framework.

Spero che questo possa aiutare a comprendere la relazione tra la superficie dell'API standard .NET e altre piattaforme .NET . Ogni interfaccia rappresenta un framework di destinazione e i metodi rappresentano gruppi di API disponibili su quel framework di destinazione.

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

fonte

Un altro modo di spiegare la differenza potrebbe essere con esempi del mondo reale, poiché la maggior parte di noi mortali utilizzerà strumenti e strutture esistenti (Xamarin, Unity, ecc.) Per fare il lavoro.

Quindi, con .NET Framework hai tutti gli strumenti .NET con cui lavorare ma puoi solo indirizzare le applicazioni Windows (UWP, Winforms, ASP.NET, ecc.). Poiché .NET Framework è di tipo chiuso, non c'è molto da fare al riguardo.

Con .NET Core hai meno strumenti ma puoi scegliere come target le principali piattaforme desktop (Windows, Linux, Mac). Ciò è particolarmente utile nelle applicazioni ASP.NET Core, poiché ora puoi ospitare Asp.net in Linux (prezzi di hosting più economici). Ora, poiché .NET Core era open source, è tecnicamente possibile sviluppare librerie per altre piattaforme. Ma dal momento che non ci sono framework che lo supportano, non credo sia una buona idea.

Con .NET Standard hai ancora meno strumenti ma puoi scegliere come target tutte / la maggior parte delle piattaforme. Puoi scegliere come target i dispositivi mobili grazie a Xamarin e persino le console di gioco grazie a Mono / Unity. Aggiornamento: è anche possibile indirizzare i client Web con piattaforma UNO e Blazor (anche se entrambi sono un po 'sperimentali in questo momento).

In un'applicazione del mondo reale potrebbe essere necessario utilizzarli tutti. Ad esempio, ho sviluppato un'applicazione point of sale che aveva la seguente architettura:

Condiviso sia server che client:

• Una libreria .NET standard che gestisce i modelli della mia applicazione.
• Una libreria .NET standard che gestisce la convalida dei dati inviati dai client.

Poiché è una libreria .NET Standard, può essere utilizzata in qualsiasi altro progetto (client e server).

Anche un bel vantaggio di avere la convalida su una libreria standard .NET poiché posso essere sicuro che la stessa convalida sia applicata sul server e sul client. Il server è obbligatorio, mentre il client è facoltativo e utile per ridurre il traffico.

Lato server (API Web):

• Una libreria .NET standard (che potrebbe anche essere Core) che gestisce tutte le connessioni al database.

• Un progetto .NET Core che gestisce l'API Rest e utilizza la libreria del database.

Poiché questo è sviluppato in .NET Core, posso ospitare l'applicazione su un server Linux.

Lato client (MVVM con WPF + Xamarin.Forms Android / IOS):

• Una libreria .NET standard che gestisce la connessione API client.

• Una libreria .NET standard che gestisce la logica ViewModels. Utilizzato in tutte le viste.

• Un'applicazione WPF di .NET Framework che gestisce le viste WPF per un'applicazione Windows. Aggiornamento: ora le applicazioni WPF possono essere .NET core, sebbene al momento funzionino solo su Windows. AvaloniaUI è una buona alternativa per creare applicazioni desktop GUI per altre piattaforme desktop.

• Una libreria .NET standard che gestisce le viste Xamarin Forms.

• Un progetto Xamarin per Android e Xamarin per IOS.

Quindi puoi vedere che c'è un grande vantaggio qui sul lato client dell'applicazione, dal momento che posso riutilizzare entrambe le librerie .NET Standard (API client e ViewModels) e creare viste senza logica per le applicazioni WPF, Xamarin e IOS.

.NET Standard: pensalo come una grande libreria standard. Quando lo si utilizza come dipendenza, è possibile creare solo librerie (.DLL), non eseguibili. Una libreria creata con standard .NET come dipendenza può essere aggiunta a un Xamarin.Android, un Xamarin.iOS, un progetto .NET Core Windows / OS X / Linux.

.NET Core: pensalo come la continuazione del vecchio framework .NET, solo che è opensource e alcune cose non sono ancora state implementate e altre sono state deprecate. Estende lo standard .NET con funzioni extra, ma funziona solo su desktop . Quando si aggiunge questo come dipendenza, è possibile creare applicazioni eseguibili su Windows, Linux e OS X. (Sebbene la console sia solo per ora, nessuna GUI). Quindi .NET Core = .NET Standard + cose specifiche del desktop.

Anche UWP lo usa e anche il nuovo ASP.NET Core lo usa come dipendenza.

.NET Standard esiste principalmente per migliorare la condivisione del codice e rendere le API disponibili in ogni implementazione .NET più coerenti.

Durante la creazione delle librerie possiamo avere l'obiettivo come .NET Standard 2.0 in modo che la libreria creata sia compatibile con diverse versioni di .NET Framework tra cui .NET Core, Mono , ecc.

Le risposte di cui sopra possono descrivere la migliore comprensione della differenza tra net core, net standard e net framwork, quindi voglio solo condividere la mia esperienza quando scelgo questo oltre a quello.

Nel progetto che è necessario combinare tra .NET Framework, .NET Core e .NET Standard. Ad esempio, al momento della creazione del sistema con .NET Core 1.0, non esiste supporto per l'hosting di servizi Windows con .net core.

Il prossimo motivo è che stavamo usando Active Report che non supporta .NET Core. Quindi vogliamo costruire una libreria di infrastruttura che può essere utilizzata sia per .NET Core (asp.net core) che per Windows Service and Reporting (.NET Framework) -> Ecco perché abbiamo scelto .NET Standard per questo tipo di libreria. Scegliere lo standard .NET significa che devi considerare attentamente ogni classe nella libreria dovrebbe essere semplice e incrociata tra .NET (core, framework, standard).

Conclusione:

• .NET standard per la libreria dell'infrastruttura e il comune condiviso. Questa lib può essere referenziata da .NET Framework e .NET Core.
• .NET Framework per tecnologie non supportate come Active Report, Window Services (ora supporta .NET 3.0).
• .NET Core per ASP.NET Core ovviamente.

Microsoft ha appena annunciato .NET 5: https://devblogs.microsoft.com/dotnet/introducing-net-5/

.NET Framework Le applicazioni Windows Form, ASP.NET e WPF devono essere sviluppate utilizzando la libreria .NET Framework

.NET Standard Xamarin, IOs e l'applicazione MAC OSx devono essere sviluppati utilizzando la libreria .NET Standard

.NET Core
Universal Windows Platform (UWP) e l'applicazione Linux devono essere sviluppati utilizzando la libreria .NET Core. L'API è implementata in C ++ e puoi usare le lingue C ++, VB.NET, C #, F # e Javascript.

Una libreria di classi core .Net è costruita sullo standard .Net. Se vuoi implementare una libreria portatile per .Net Framework, .Net Core e Xamarin, scegli una .Net Standard Library