Quali sono le piattaforme in .NET Platform Standard?

Question

Attualmente sto cercando di conoscere .NET Platform Standard. Mi sono trovato piuttosto confuso sull'idea di "piattaforme diverse".

Proverò a chiarire il punto. Quello che attualmente mi riferisco a .NET Framework è che .NET è grosso modo composto da CLR, BCL e software di supporto per avviare il CLR e fornire l'interfaccia tra la macchina virtuale e il sistema operativo sottostante.

Quindi, quando eseguiamo il codice utilizzando .NET Framework, abbiamo effettivamente scelto alcune versioni del framework perché i tipi che utilizziamo dal BCL vengono forniti con il framework e quindi dipendono dalla versione specifica.

Ora, .NET Core è molto diverso come ho capito. Non è tutto imballato insieme in quel modo. Abbiamo il CoreCLR che è una VM leggera per eseguire IL, il CoreFX che sono le librerie opportunamente organizzate come pacchetti NuGet e avevamo fino ad ora il DNX/DNVM/DNU che forniva le cose di supporto come l'avvio del CoreCLR e l'interfacciamento con il OS.

In ogni caso, nonostante installiamo il framework su Windows 7, Windows 8 o Windows 10, codifichiamo rispetto al framework.

Ora, sulla spec .NET Platform Standard vediamo la seguente definizione:

piattaforma - per esempio .NET Framework 4.5, .NET Framework 4.6, Windows Phone 8.1, MonoTouch, UWP, ecc

Inoltre vediamo dopo che un elenco di piattaforme, che include

• .NET Framework 2,0-4,6
• Windows 8
• Windows Phone 8.1
• Silverlight 4, 5
• DNX su .NET Framework 4.5.1 - 4.6
• DNX su .NET Core 5.0

Ora questo mi confonde completamente. Ho sempre pensato: abbiamo codice contro .NET Framework e il framework è il framework, non importa cosa.

Ma qui abbiamo queste piattaforme che includono il framework .NET come solo una delle molte piattaforme. Abbiamo ad esempio Windows 8, ma aspetta un minuto, l'esecuzione di .NET su Windows 8 non è la stessa cosa che eseguire .NET su qualsiasi altro sistema operativo? Perché è separato dalla piattaforma .NET Framework 2.0 - 4.6?

Abbiamo anche DNX come piattaforma specifica. Questo mi fa meravigliare: la piattaforma è quella "roba di supporto" relativa all'avvio della macchina virtuale e alla fornitura dell'interfaccia con il sistema operativo? O la piattaforma include la macchina virtuale?

In ogni caso, come si può vedere, sono abbastanza confuso. Quali sono effettivamente queste piattaforme e in che modo si riferisce alla mia attuale conoscenza di .NET Framework? Inoltre, perché .NET Framework 2.0 - 4.6 è descritto separatamente? Non è il tutto descritto qui qualche versione di .NET Framework a meno di .NET Core?

Answer 1

Esistono molti Framework (.NET Framework, WinRT, UWP, Silverlight,.NET Core, Windows Phone, Mono, Micro Framework e il vecchio Compact Framework) e non solo .NET Framework.

Il nuovo modo è programmare su uno standard di piattaforma che supporta uno o più di questi framework. Lo standard della piattaforma definisce un'API che corrisponde a uno o più framework. Ciò significa che se la tua applicazione supporta la piattaforma standard 1.1 probabilmente sosterrai quasi tutti i framework. Piattaforma standard 1.4 supporterà 4.6.x di .NET Framework e .NET core solo

Date un'occhiata a questo documento: https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

Answer 2

codice che abbiamo contro il quadro.

Beh, certo che lo sei. Quando manipoli le stringhe nel tuo codice, utilizzerai sempre System.String. E (quasi) si comporta sempre nello stesso modo con gli stessi identici metodi e proprietà.

Ma visualizzazione la stringa non ha dettagli di implementazione che non si può davvero ignorare:

• Se si desidera visualizzare in un terminale Unix su Linux o OSX, allora avete bisogno di indirizzare Mono o CoreCLR, il implementazioni di framework che possono essere eseguite su tali sistemi operativi.
• Se vuoi mostrarlo in un'app di Windows Store (ovvero WinRT, ovvero Windows 8, ovvero UWP), in realtà è un HSTRING sotto il cofano, un dettaglio molto ben nascosto di cui non devi preoccuparti. Ma richiede un gadget dell'interfaccia utente, come Windows.UI.Xaml.Controls.TextBlock, una classe che è altamente specifica per WinRT
• Se si desidera visualizzarlo in un browser, è necessario scegliere come destinazione ASP.NET o Silverlight, framework host ottimizzati per l'esecuzione su un server Web o come componente aggiuntivo per un browser.
• Se vuoi mostrarlo su un dispositivo che è alimentato da una piccola batteria agli ioni di litio, come un telefono, allora dovrai inevitabilmente avere a che fare con una versione di framework ottimizzata per usare meno energia possibile. Che fa influenza il codice che devi scrivere, c'è un'enorme differenza tra il codice che brucia 100 Watt e il codice che mantiene in vita una piccola batteria per 8 ore. Nulla di ciò che si può vedere direttamente, oltre alla necessità di usare async/attendere molto, ma sicuramente qualcosa che ha influito molto sul runtime. È richiesto il targeting di Xamarin o WinRT.
• Se si desidera visualizzarlo su su qualsiasi sistema operativo, è necessario scegliere una versione di framework che non utilizzi il tipo di trucchi che .NET utilizza su Windows per fare in modo che EXE avvii la macchina virtuale CLR. Ciò richiede dnx.exe, proprio come se dovessi usare java.exe o python.exe per programmi scritti in Java o Python.

Sarebbe bello se quei dettagli di implementazione non fossero importanti. Ma non il modo in cui funziona nella pratica, dato che .NET prolifera e diventa disponibile su un numero sempre maggiore di dispositivi e sistemi operativi, inevitabilmente diventa anche più complicato. Scegli i tuoi bersagli in anticipo, è importante.

Answer 3

Ora questo mi confonde completamente. Ho sempre pensato: abbiamo codice contro .NET Framework e il framework è il framework, non importa cosa.

No, ci sono in realtà più framework o piattaforme .NET come ti piace chiamarli. Prima di .NET Standard, si utilizzava come target un singolo framework (forse quello completo, attualmente alla versione 4.6.3, se si sviluppano applicazioni Web o servizi Windows).Le DLL che mirano a un framework non sono compatibili con un altro. OSSIA una DLL sviluppata per il framework .NET completo non può essere eseguita su Windows Phone 8.1.

Questi framework implementano in realtà un insieme abbastanza piccolo di librerie, ma anche librerie specifiche per gestire la piattaforma a cui sono destinate. OSSIA librerie per la gestione di un server Web ospitato su IIS nel framework .NET completo o funzioni per la gestione di un telefono cellulare nel framework Windows Phone 8.1.

Prima era NET standard PCL

C'era anche una soluzione, denominata PCL che sta per "Class Libraries portatili". Usando solo il piccolo sottoinsieme comune di metodi/assiemi in due o più framework .NET, si potrebbe sviluppare una libreria che potrebbe essere inclusa in progetti destinati a diversi framework. Ad esempio, il profilo 37 PCL significa che vuoi che la tua libreria sia utilizzabile nei progetti .NET Framework 4, Silverlight 5 e Windows 8.

prega di dare un'occhiata a questo per un elenco dei profili PCL e dei loro compatibilità (non so se è esaustivo): http://danrigby.com/2014/05/14/supported-pcl-profiles-xamarin-for-visual-studio-2/

Ora che dire di .NET standard?

L'obiettivo con .NET Standard è semplificare questo e sbarazzarsi di PCL. Approssimativamente, .NET Standard definisce un contratto (un insieme di classi e metodi), che sarà implementato da tutti i framework .NET. Se si sviluppa una libreria destinata a .NET Standard, si è certi che può essere eseguita su tutti i framework .NET. È l'idea/l'obiettivo di base dietro di esso (anche se è un po 'più sottile).

Date un'occhiata a questo per l'esatta compatibilità: https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/#user-content-whats-new-in-net-standard-20

Se si guarda la tabella di compatibilità, vedrai che una libreria .NET mira standard 1.6 è utilizzabile come è (non è necessario ricompilare) in .NET Framework 4.6.3 e .NET Core 1.0.

In altre parole, possiamo dire che .NET Framework 4.6.3 e .NET Core 1.0 implementano entrambi il contratto Standard 1.6 Standard: le sue classi e metodi.

Se si desidera che la DLL sia utilizzabile in un progetto Windows Phone 8.1, è necessario scegliere .NET Standard 1.2, che offre meno funzioni di .NET Standard 1.6 (nessun System.Net.Sockets per esempio) .

Vedi qui per un elenco di spazi dei nomi disponibili in ogni versione di .NET standard https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md#user-content-list-of-net-corefx-apis-and-their-associated-net-platform-standard-version