Qual è la differenza tra i tipi di progetto .NET Core e .NET Standard Class Library?
In Visual Studio sono disponibili almeno tre diversi tipi di librerie 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 usiamo da anni, un punto di grande confusione che ho avuto è quando usare i tipi di libreria di classi .NET Standard e .NET Core. Sono stato colpito da questo di recente quando ho tentato di multi-target diverse versioni di framework e ho creato un progetto di unit test .
Allora, qual è la differenza tra Class Library (.NET Standard) e Class Library (.NET Core) , perché esistono entrambe e quando dovremmo usarne una sull'altra?
Risposte
Quando dovremmo usarne uno sull'altro?
La decisione è un compromesso tra compatibilità e accesso API.
Usa una libreria .NET Standard quando vuoi aumentare il numero di applicazioni che saranno compatibili con la tua libreria e sei d'accordo con una diminuzione della superficie dell'API .NET a cui la tua libreria può accedere.
Usa una libreria .NET Core quando vuoi aumentare l'area di superficie dell'API .NET a cui la tua libreria può accedere e puoi consentire solo alle applicazioni .NET Core di essere compatibili con la tua libreria.
Ad esempio, una libreria destinata a .NET Standard 1.3 sarà compatibile con le applicazioni 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)?
Compatibilità: le librerie destinate a .NET Standard verranno eseguite su qualsiasi runtime compatibile con .NET Standard, come .NET Core, .NET Framework, Mono / Xamarin . D'altra parte, le librerie destinate a .NET Core possono essere eseguite solo nel runtime .NET Core.
Superficie API: le librerie .NET Standard sono dotate di tutto NETStandard.Library, mentre le librerie .NET Core includono 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 delle quali 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, per rendere eseguibili le librerie di classi di unit test.
Perché esistono entrambi?
Ignorando per un momento le librerie, il motivo per cui esiste .NET Standard è per la portabilità; definisce un insieme di API che le piattaforme .NET accettano di implementare. Qualsiasi piattaforma che implementa .NET Standard è compatibile con le librerie destinate a .NET Standard. 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 API). Al contrario, i modelli di libreria .NET Core esistono per accedere a una maggiore superficie API (a scapito della compatibilità) e per specificare una piattaforma su cui creare un eseguibile.
Ecco una matrice interattiva che mostra quale .NET Standard supporta quali implementazioni .NET e quanta area di superficie API è disponibile.
Una libreria di classi .NET Core è basata su .NET Standard . Se desideri implementare una libreria portabile su .NET Framework , .NET Core e Xamarin , scegli una libreria .NET Standard
.NET Core alla fine implementerà .NET Standard 2 (così come Xamarin e .NET Framework )
.NET Core , Xamarin e .NET Framework possono quindi essere identificati come versioni di .NET Standard
Per rendere le applicazioni a prova di futuro 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 portabili .
Per citare MSDN come fonte autorevole, .NET Standard è concepito come una libreria per domarli tutti . Poiché le immagini valgono più di mille parole, quanto segue renderà le cose molto chiare:
1. Il tuo attuale scenario applicativo (frammentato)
Come la maggior parte di noi, probabilmente ti trovi nella situazione seguente: (.NET Framework, Xamarin e ora applicazioni con il gusto di .NET Core)
2. Cosa ti consentirà la libreria .NET Standard (compatibilità cross-framework)
L'implementazione di una libreria .NET Standard consente la condivisione del codice tra tutti questi diversi gusti:
Per gli impazienti:
- .NET Standard risolve il problema della 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 mobili e servizi cloud:
- .NET Standard è un insieme di API che tutte le piattaforme .NET devono implementare . Ciò unifica le piattaforme .NET e impedisce la futura frammentazione .
- NET standard 2.0 sarà attuato da .NET Framework ,. NET Core e Xamarin . Per .NET Core , verranno aggiunte molte delle API esistenti che sono state richieste.
- .NET Standard 2.0 include uno shim di compatibilità per i file binari di .NET Framework , aumentando in modo significativo il set di librerie a cui puoi fare riferimento dalle tue librerie .NET Standard.
- .NET Standard sostituirà le librerie di classi portatili (PCL) come storia degli strumenti per la creazione di librerie .NET multipiattaforma.
Per una tabella che ti aiuti a capire quale sia la versione più alta di .NET Standard che puoi targetizzare, in base alle piattaforme .NET su cui intendi eseguire, vai qui .
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 assembly che Microsoft ha creato per .NET, a seconda di dove sono installati e in quale profilo.
Ad esempio, sono disponibili alcune API diverse nelle app di Windows universali rispetto al profilo di Windows "normale". Anche su Windows, potresti avere il profilo "Client" rispetto al profilo "Completo". Inoltre, 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 e così via, che pubblicizza il supporto per la raccolta di librerie .NET Standard 1.0. Lo stesso vale per .NET Standard 1.1, 1.5, 1.6, 2.0, ecc. Finché il runtime fornisce il supporto per la versione di Standard scelta dal programma, il programma dovrebbe essere eseguito lì.
Un progetto mirato a una versione dello standard non sarà in grado di utilizzare caratteristiche che non sono incluse in quella revisione dello standard. Ciò non significa che non puoi prendere dipendenze da altri assembly o API pubblicate da altri fornitori (ad esempio: elementi su NuGet). Ma significa che qualsiasi dipendenza che prendi deve 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 allo standard dovrebbe essere in grado di essere utilizzata in più situazioni di distribuzione, poiché in teoria può essere eseguita con Core, Framework, Mono, ecc. Per un progetto di libreria di classi che cerca un'ampia distribuzione, questa è una promessa allettante . Per un progetto di libreria di classi utilizzato principalmente per scopi interni, potrebbe non essere così preoccupante.
.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 in modo autonomo e dovrebbe essere referenziato da un altro progetto eseguibile .NET Core o .NET Framework.
Un altro modo per spiegare la differenza potrebbe essere con esempi del mondo reale, poiché la maggior parte di noi semplici mortali utilizzerà strumenti e framework esistenti ( Xamarin , Unity , ecc.) Per svolgere il lavoro.
Quindi, con .NET Framework hai tutti gli strumenti .NET con cui lavorare, ma puoi scegliere come target solo le applicazioni Windows ( UWP , Windows Forms , ASP.NET , ecc.). Poiché .NET Framework è closed source, non c'è molto da fare al riguardo.
Con .NET Core hai meno strumenti, ma puoi scegliere come target le principali piattaforme desktop (Windows, Linux e Mac). Ciò è particolarmente utile nelle applicazioni ASP.NET Core, poiché ora è possibile ospitare ASP.NET su Linux (prezzi di hosting più economici). Ora, poiché .NET Core era open source, è tecnicamente possibile sviluppare librerie per altre piattaforme. Ma poiché 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 puoi persino scegliere come target le console di gioco grazie a Mono / Unity. È anche possibile indirizzare i client Web con la piattaforma UNO e Blazor (sebbene entrambi siano al momento sperimentali).
In un'applicazione reale potrebbe essere necessario utilizzarli tutti. Ad esempio, ho sviluppato un'applicazione per punto vendita che aveva la seguente architettura:
Condiviso sia server che slient:
- 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 certo che la stessa convalida viene applicata sul server e sul client. Il server è obbligatorio, mentre il client è opzionale e utile per ridurre il traffico.
Lato server (API Web):
Una libreria .NET Standard (potrebbe essere anche .NET Core) che gestisce tutte le connessioni al database.
Un progetto .NET Core che gestisce l'API Rest e utilizza la libreria di database.
Poiché è 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 . Viene utilizzato in tutte le viste.
Un'applicazione WPF .NET Framework che gestisce le visualizzazioni WPF per un'applicazione Windows. Le applicazioni WPF possono essere .NET core ora, anche se attualmente funzionano solo su Windows. AvaloniaUI è una buona alternativa per creare applicazioni GUI desktop per altre piattaforme desktop.
Una libreria .NET Standard che gestisce le visualizzazioni dei moduli Xamarin.
Un progetto Xamarin Android e Xamarin iOS .
Quindi puoi vedere che c'è un grande vantaggio qui sul lato client dell'applicazione, poiché posso riutilizzare entrambe le librerie .NET Standard ( API client e ViewModels) e creare visualizzazioni senza logica per le applicazioni WPF, Xamarin e iOS.
Spero che questo aiuti a capire la relazione tra la superficie API .NET Standard e altre piattaforme .NET . Ogni interfaccia rappresenta un framework di destinazione e i metodi rappresentano i 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
}
}
.NET Standard: pensala come una grande libreria standard. Quando lo usi come dipendenza puoi solo creare librerie (.DLL), non eseguibili. Una libreria realizzata con .NET standard come dipendenza può essere aggiunta a un progetto Xamarin.Android, Xamarin.iOS, .NET Core Windows / OS X / Linux.
.NET Core: pensalo come la continuazione del vecchio framework .NET, è solo opensource e alcune cose non sono ancora 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. (Anche se per ora solo console, nessuna GUI). Quindi .NET Core = .NET Standard + cose specifiche per 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 come target .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 precedenti possono descrivere la migliore comprensione della differenza tra .NET Core, .NET Standard e .NET Framework, quindi voglio solo condividere la mia esperienza quando scelgo questo rispetto a quello.
Nel progetto è necessario combinare .NET Framework, .NET Core e .NET Standard. Ad esempio, al momento della creazione del sistema con .NET Core 1.0, non è disponibile il supporto per l'hosting di Windows Services con .NET Core.
Il motivo successivo è che stavamo utilizzando Active Report che non supporta .NET Core.
Quindi vogliamo costruire una libreria di infrastruttura che possa 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. La scelta dello standard .NET significa che è necessario considerare attentamente ogni classe nella libreria dovrebbe essere semplice e trasversale a .NET (Core, Framework e Standard).
Conclusione:
- .NET Standard per la libreria dell'infrastruttura e comune condiviso. Questa libreria può essere referenziata da .NET Framework e .NET Core.
- .NET Framework per tecnologie non supportate come Active Report, Window Services (ora con .NET 3.0 supporta).
- .NET Core per ASP.NET Core ovviamente.
Microsoft ha appena annunciato .NET 5: Introduzione a .NET 5
Una libreria di classi .NET Core è basata su .NET Standard. Se vuoi implementare una libreria portabile su .NET Framework, .NET Core e Xamarin, scegli una libreria .NET Standard.
.NET Framework
Le applicazioni Windows Form , ASP.NET e WPF devono essere sviluppate utilizzando la libreria .NET Framework.
.NET Standard
L'applicazione Xamarin, iOS e Mac OS X deve essere sviluppata utilizzando la libreria .NET Standard
.NET Core
La piattaforma UWP ( Universal Windows Platform ) e l'applicazione Linux devono essere sviluppate utilizzando la libreria .NET Core. L'API è implementata in C ++ e puoi utilizzare i linguaggi C ++, VB.NET, C #, F # e JavaScript.