Microsoft nella conferenza che si è conclusa il 25 settembre 2019 ha annunciato il rilascio di .NET Core 3.0.
Include molti miglioramenti, tra cui l'aggiunta di Windows Form e WPF, l'aggiunta di nuove API JSON, il supporto per ARM64 e il miglioramento delle prestazioni su tutta la linea. Anche C # 8 fa parte di questa versione, che include nullable, async streams e altri pattern. F # 4.7 è incluso e focalizzato sul rilassamento della sintassi e sul targeting di .NET Standard 2.0. Oggi puoi iniziare ad aggiornare i progetti esistenti per targetizzare .NET Core 3.0. Il rilascio è compatibile con le versioni precedenti, facilitando l'aggiornamento.
Guarda il team e la community parlare di about .NET at .NET Conf, live NOW!
Puoi scaricare download .NET Core 3.0, per Windows, macOS, and Linux:
ASP.NET Core 3.0 e EF Core 3.0 per Mac 8.3 sono stati rilasciati oggi e sono necessari aggiornamenti per utilizzare Visual Studio 2019 16.3 e Visual Studio for Mac 8.3 inoltre sono stati rilasciati oggi e sono necessari aggiornamenti per utilizzare .NET Core 3.0 con Visual Studio. .NET Core 3.0 fa parte di Visual Studio 2019 16.3. Puoi semplicemente ottenere .NET Core semplicemente aggiornando Visual Studio 2019 16.3.
Grazie a tutti coloro che hanno contribuito a .NET Core 3.0! Centinaia di persone sono state coinvolte nel realizzare questa versione, inclusi importanti contributi della comunità.
Cosa dovresti sapere su 3.0
Ci sono alcuni miglioramenti e indicazioni chiave su cui è importante porre l'attenzione prima di approfondire tutte le nuove funzionalità di .NET Core 3.0. Ecco l'elenco rapido dei pugni.
- .NET Core 3.0 è già stato testato in battaglia essendo ospitato per mesi su dot.net e su Bing.com.. Molti altri team Microsoft presto distribuiranno grandi carichi di lavoro su .NET Core 3.0 in produzione.
- Le prestazioni sono notevolmente migliorate in molti componenti e sono descritte in dettaglio i miglioramenti delle prestazioni in .NET Core 3.0.
- C # 8 aggiunge Asyncs streams, range/index, più altri modelli e tipi di riferimento nullabili. Nullable ti consente di indirizzare direttamente i difetti nel codice che portano a
NullReferenceException.Il livello più basso delle librerie del framework è stato annotato, in modo da sapere quando aspettarsi null. - F # 4.7 si concentra sul rendere alcune cose più facili con espressioni di resa implicite e alcuni rilassamenti della sintassi. Include anche il supporto per LangVersion e viene fornito con il nome di e l'apertura di classi statiche in anteprima. La libreria F # Core ora punta anche a .NET Standard 2.0. Puoi leggere di più su Annunciando F # 4.7.
.NET Standard 2.1 aumenta l'insieme di tipi che è possibile utilizzare nel codice che può essere utilizzato con .NET Core e Xamarin. .NET Standard 2.1 include tipi da .NET Core 2.1.
- Le app desktop di Windows sono ora supportate con .NET Core, sia per Windows Form che per WPF (e open source). Il designer WPF fa parte di Visual Studio 2019 16.3. Il designer di Windows Form è ancora in anteprima e disponibile come download VSIX.
- Le app .NET Core ora hanno eseguibili per impostazione predefinita. Nelle versioni precedenti, le app dovevano essere avviate tramite il comando dotnet, come dotnet myapp.dll. Le app possono ora essere avviate con un eseguibile specifico dell'app, come myapp o ./myapp, a seconda del sistema operativo.
- Sono state aggiunte API JSON ad alte prestazioni, per scenari di lettura / scrittura, modello a oggetti e serializzazione. Queste API sono state costruite da zero sopra Span <T> e usano UTF8 sotto le copertine invece di UTF16 (come la stringa). Queste API riducono al minimo le allocazioni, garantendo prestazioni più rapide e molto meno lavoro per il Garbage Collector. Vedi Il futuro di JSON in .NET Core 3.0.
- Il Garbage Collector utilizza meno memoria per impostazione predefinita, spesso molto meno. Questo miglioramento è molto utile per gli scenari in cui molte applicazioni sono ospitate sullo stesso server. Anche il Garbage Collector è stato aggiornato per utilizzare meglio un gran numero di core, su macchine con> 64 core.
- .NET Core è stato potenziato per Docker per consentire alle applicazioni .NET di funzionare in modo prevedibile ed efficiente nei container. Il Garbage Collector e il pool di thread sono stati aggiornati per funzionare molto meglio quando un contenitore è stato configurato per memoria o CPU limitate. Le immagini docker .NET Core sono più piccole, in particolare l'immagine SDK.
- I chip Raspberry Pi e ARM sono ora supportati per consentire lo sviluppo dell'IoT, anche con il debugger di Visual Studio remoto. Puoi distribuire app che ascoltano i sensori e stampare messaggi o immagini su uno schermo, il tutto utilizzando le nuove API GPIO. ASP.NET può essere utilizzato per esporre i dati come API o come sito che consente la configurazione di un dispositivo IoT.
- .NET Core 3.0 è una versione "corrente" e sarà sostituita da .NET Core 3.1, prevista per novembre 2019. .NET Core 3.1 sarà una versione supportata a lungo termine (LTS) (supportata per almeno 3 anni). È consigliabile adottare .NET Core 3.0 e quindi adottare 3.1. Sarà molto facile aggiornarlo.
- .NET Core 2.2 andrà in EOL il 12/23 poiché è ora la precedente versione "corrente". Vedi la politica di supporto di .NET Core.
- .NET Core 3.0 sarà disponibile con RHEL 8 in Red Hat Application Streams, dopo diversi anni di collaborazione con Red Hat.
- Visual Studio 2019 16.3 è un aggiornamento obbligatorio per gli utenti di Visual Studio su Windows che desiderano utilizzare .NET Core 3.0.
- Visual Studio per Mac 8.3 è un aggiornamento necessario per gli utenti di Visual Studio per Mac che desiderano utilizzare .NET Core 3.0.
- Gli utenti di Visual Studio Code devono sempre utilizzare l'ultima versione dell'estensione C # per garantire il funzionamento degli scenari più recenti, incluso il targeting .NET Core 3.0.
- La distribuzione del servizio app di Azure di .NET Core 3.0 è attualmente in corso.
- La distribuzione di Azure Dev Ops di .NET Core 3.0 è in arrivo. Si aggiornerà quando sarà disponibile.
Supporto per la piattaforma
.NET Core 3.0 è supportato sui seguenti sistemi operativi:
- Alpine: 3.9+
- Debian: 9+
- openSUSE: 42.3+
- Fedora: 26+
- Ubuntu: 16.04+
- RHEL: 6+
- SLES: 12+
- macOS: 10.13+
- Windows Client: 7, 8.1, 10 (1607+)
- Windows Server: 2012 R2 SP1+
Nota: Windows Form e le app WPF funzionano solo su Windows.
Segue il supporto del chip:
- x64 on Windows, macOS, and Linux
- x86 on Windows
- ARM32 on Windows and Linux
- ARM64 on Linux (kernel 4.14+)
Nota: assicurarsi che le distribuzioni ARM64 .NET Core 3.0 utilizzino la versione 4.14 o successiva del kernel Linux. Ad esempio, Ubuntu 18.04 soddisfa questo requisito, ma 16.04 no.
WPF e Windows Form
Puoi creare app WPF e Windows Form con .NET Core 3, su Windows. Abbiamo avuto un forte obiettivo di compatibilità fin dall'inizio del progetto, per facilitare la migrazione delle applicazioni desktop da .NET Framework a .NET Core. Abbiamo ricevuto feedback da molti sviluppatori che hanno già portato con successo la loro app a .NET Core 3.0 che il processo è semplice. In larga misura, abbiamo preso WPF e Windows Form così come sono e li abbiamo fatti funzionare su .NET Core. Il progetto di ingegneria era molto diverso da quello, ma è un buon modo di pensare al progetto.
L'immagine seguente mostra un'app di Windows Form per .NET Core:
Visual Studio 2019 16.3 supporta la creazione di app WPF destinate a .NET Core. Ciò include nuovi modelli e un designe XAML aggiornato e XAML Hot Reload. Il designe è simile al designer XAML esistente (destinato a .NET Framework), tuttavia, potresti notare alcune differenze nell'esperienza. La grande differenza tecnica è che il progettista di .NET Core utilizza un nuovo processo di superficie (wpfsurface.exe) per eseguire esclusivamente il codice di runtime destinato alla versione di .NET Core. In precedenza, il processo di progettazione WPF di .NET Framework (xdesproc.exe) era di per sé un processo di .NET Framework WPF che ospitava il progettista e, a causa dell'incompatibilità di runtime, non è possibile disporre di un processo di .NET Framework WPF (in questo caso, Visual Studio ) caricamento di due versioni di .NET (.NET Framework e .NET Core) nello stesso processo. Ciò significa che alcuni aspetti del designer, come le estensioni del designer, non possono funzionare allo stesso modo. Se stai scrivendo estensioni di design, ti consigliamo di leggere XAML designer extensibility migration.
Microsoft ha reso Windows Forms e WPF open source, a dicembre 2018. È stato bello vedere la community e i team di Windows Form e WPF lavorare insieme per migliorare i framework dell'interfaccia utente. Nel caso di WPF, abbiamo iniziato con una quantità molto piccola di codice nel repository GitHub. A questo punto, quasi tutto il WPF è stato pubblicato su GitHub e alcuni altri componenti si spargeranno nel tempo. Come altri progetti .NET Core, questi nuovi repository fanno parte di .NET Foundation e sono concessi in licenza con la licenza MIT.
Interoperabilità nativa di Windows
Windows offre una ricca API nativa, sotto forma di API C piatte, COM e WinRT. Abbiamo supportato P / Invoke da .NET Core 1.0 e abbiamo aggiunto la possibilità di CoCreate API COM, attivazione di API WinRT e codice gestito esposto come componenti COM come parte della versione .NET Core 3.0. Abbiamo ricevuto molte richieste per queste funzionalità, quindi sappiamo che ne trarranno grande utilità.
Alla fine dell'anno scorso, abbiamo annunciato che siamo riusciti ad automatizzare Excel da .NET Core. È stato un momento divertente. Sotto le copertine, questa demo utilizza funzionalità di interoperabilità COM come NOPIA, equivalenza di oggetti e marshaller personalizzati. Ora puoi provare tu stesso e altre demo negli esempi di estensione.
L'interoperabilità C ++ gestita e WinRT ha un supporto parziale con .NET Core 3.0 e sarà inclusa in .NET Core 3.1.
Le novità di C# 8.0
Tipi di riferimento nullabili
C # 8.0 introduce tipi di riferimento nullable e tipi di riferimento non nullable che consentono di fare dichiarazioni importanti sulle proprietà per le variabili del tipo di riferimento:
Un riferimento non dovrebbe essere nullo. Quando non si suppone che le variabili siano nulle, il compilatore applica regole che assicurano che sia sicuro sottovalutare queste variabili senza prima verificare che non sia nullo.
Un riferimento può essere nullo. Quando le variabili possono essere nulle, il compilatore applica regole diverse per garantire che sia stato verificato correttamente un riferimento null.
Questa nuova funzionalità offre vantaggi significativi rispetto alla gestione delle variabili di riferimento nelle versioni precedenti di C # in cui non è stato possibile determinare l'intento di progettazione dalla dichiarazione delle variabili. Con l'aggiunta di tipi di riferimento nullable, puoi dichiarare il tuo intento in modo più chiaro e il compilatore ti aiuta a farlo correttamente e a scoprire bug nel tuo codice.
Guarda This is how you get rid of null reference exceptions forever, Try out Nullable Reference Types and Nullable reference types per saperne di più.
Implementazioni predefinite dei membri dell'interfaccia
Oggi, una volta pubblicata un'interfaccia, è finita per cambiarla: non è possibile aggiungere membri ad essa senza interrompere tutti gli implementatori esistenti di essa.
Con C # 8.0, è possibile fornire un corpo per un membro dell'interfaccia. Di conseguenza, se una classe che implementa l'interfaccia non implementa quel membro (forse perché non era ancora presente quando hanno scritto il codice), il codice chiamante otterrà invece l'implementazione predefinita.
In questo esempio, la classe ConsoleLogger non deve implementare il sovraccarico Log (Eccezione) di ILogger, poiché è dichiarato con un'implementazione predefinita. Ora è possibile aggiungere nuovi membri alle interfacce pubbliche esistenti purché si fornisca un'implementazione predefinita da utilizzare per gli implementatori esistenti.
Flussi asincroni
È ora possibile eseguire la foreach su un flusso di dati asincrono utilizzando IAsyncEnumerable<T>. Questa nuova interfaccia è esattamente quello che ti aspetteresti; una versione asincrona di IEnumerable<T>.
La lingua ti consente di attendere ogni compito per consumare i loro elementi. Dal lato della produzione, si producono articoli di ritorno per produrre un flusso asincrono. Potrebbe sembrare un po 'complicato, ma è incredibilmente facile in pratica.
L'esempio seguente mostra sia la produzione che il consumo di flussi asincroni. L'istruzione foreach è asincrona e utilizza essa stessa il rendimento per produrre un flusso asincrono per i chiamanti. Questo modello, che utilizza il rendimento, è il modello consigliato per la produzione di flussi asincroni.
Oltre ad essere in grado di attendere foreach, puoi anche creare iteratori asincroni, ad es. un iteratore che restituisce un IAsyncEnumerable / IAsyncEnumerator che puoi sia attendere sia restituire. Per gli oggetti che devono essere eliminati, puoi usare IAsyncDisposable, che implementano vari tipi di framework, come Stream e Timer.
Indice e intervallo
Abbiamo creato una nuova sintassi e tipi che puoi utilizzare per descrivere gli indicizzatori, per l'accesso agli elementi dell'array o per qualsiasi altro tipo che esponga l'accesso diretto ai dati. Ciò include il supporto sia per un singolo valore - la solita definizione di un indice - o due valori, che descrivono un intervallo.
L'indice è un nuovo tipo che descrive un indice di array. È possibile creare un indice da un int che conta dall'inizio o con un operatore prefisso ^ che conta dalla fine. Puoi vedere entrambi i casi nel seguente esempio:
L'intervallo è simile, costituito da due valori di indice, uno per l'inizio e uno per la fine e può essere scritto con un'espressione di intervallo x..y. È quindi possibile indicizzare con un intervallo per produrre una porzione dei dati sottostanti, come dimostrato nell'esempio seguente:
Usando le dichiarazioni
Sei stanco di usare istruzioni che richiedono il rientro del tuo codice? Non piu! È ora possibile scrivere il seguente codice, che allega una dichiarazione di utilizzo all'ambito del blocco di istruzioni corrente e quindi elimina l'oggetto alla fine di esso.
Cambia espressioni
Chiunque usi C # probabilmente ama l'idea di un'istruzione switch, ma non la sintassi. C # 8 introduce le espressioni switch, che consentono quanto segue:
sintassi terser
restituisce un valore poiché è un'espressione
completamente integrato con pattern matching
La parola chiave switch è "infix", nel senso che la parola chiave si trova tra il valore testato (che è o nel primo esempio) e l'elenco dei casi, in modo molto simile all'espressione lambdas.
I primi esempi usano la sintassi lambda per i metodi, che si integra bene con le espressioni switch ma non è richiesta.
Ci sono due modelli in gioco in questo esempio. o prima coincide con il modello di tipo Punto e poi con il modello di proprietà all'interno di {parentesi graffe}. _ Descrive il modello di scarto, che è lo stesso di default per le istruzioni switch.
Puoi fare un ulteriore passo avanti e fare affidamento sulla decostruzione della tupla e sulla posizione dei parametri, come puoi vedere nell'esempio seguente:
In questo esempio, puoi vedere che non è necessario definire una variabile o un tipo esplicito per ciascuno dei casi. Al contrario, il compilatore può abbinare la tupla in fase di test con le tuple definite per ciascuno dei casi.
Tutti questi schemi ti consentono di scrivere un codice dichiarativo che cattura il tuo intento invece del codice procedurale che implementa i test per esso. Il compilatore diventa responsabile dell'implementazione di quel noioso codice procedurale ed è garantito che lo faccia sempre correttamente.
Ci saranno ancora casi in cui le istruzioni switch saranno una scelta migliore di quanto le espressioni switch e i pattern possano essere usati con entrambi gli stili di sintassi.
Presentazione di un'API JSON veloce
.NET Core 3.0 include una nuova famiglia di API JSON che consente scenari di lettura / scrittura, accesso casuale con un modello a oggetti di documento (DOM) e un serializzatore. Probabilmente hai familiarità con l'utilizzo di Json.NET. Le nuove API hanno lo scopo di soddisfare molti degli stessi scenari, ma con meno memoria e un'esecuzione più rapida.
Puoi vedere la motivazione iniziale e la descrizione del piano in Il futuro di JSON in .NET Core 3.0. Ciò include James Netwon-King, l'autore di Json.Net, che spiega perché è stata creata una nuova API, anziché estendere Json.NET. In breve, volevamo creare una nuova API JSON che sfruttasse tutte le nuove funzionalità di prestazioni in .NET Core e offrisse prestazioni in linea con quelle. Non è stato possibile farlo in una base di codice esistente come Json.NET mantenendo la compatibilità.
Diamo un'occhiata alla nuova API, strato per strato.
Presentazione del nuovo SqlClient
SqlClient è il fornitore di dati che usi per accedere a Microsoft SQL Server e al database SQL di Azure, tramite uno dei popolari O / RM .NET, come EF Core o Dapper, o direttamente usando le API ADO.NET. Ora verrà rilasciato e aggiornato come pacchetto NuGet Microsoft.Data.SqlClient e supportato sia per le applicazioni .NET Framework che .NET Core. Utilizzando NuGet, sarà più facile per il team SQL fornire aggiornamenti sia agli utenti .NET Framework che .NET Core.
Supporto ARM e IoT
Abbiamo aggiunto il supporto per ARM64 Linux questa versione, dopo aver aggiunto il supporto per ARM32 per Linux e Windows in .NET Core 2.1 e 2.2, rispettivamente. Mentre alcuni carichi di lavoro IoT sfruttano le nostre capacità x64 esistenti, molti utenti hanno richiesto il supporto ARM. Ora è attivo e stiamo lavorando con clienti che stanno pianificando implementazioni di grandi dimensioni.
Molte distribuzioni IoT che utilizzano .NET sono dispositivi periferici e completamente orientate alla rete. Altri scenari richiedono l'accesso diretto all'hardware. In questa versione, abbiamo aggiunto la possibilità di utilizzare porte seriali su Linux e sfruttare i pin digitali su dispositivi come Raspberry Pi. I pin utilizzano una varietà di protocolli. Abbiamo aggiunto il supporto per GPIO, PWM, I2C e SPI, per consentire la lettura dei dati dei sensori, l'interazione con le radio e la scrittura di testo e immagini sui display e molti altri scenari.
Questa funzionalità è disponibile come parte dei seguenti pacchetti:
Come parte del supporto per GPIO (e amici), abbiamo dato un'occhiata a ciò che era già disponibile. Abbiamo trovato API per C # e anche Python. In entrambi i casi, le API erano wrapper su librerie native, che erano spesso concesse in licenza come GPL. Non abbiamo visto un percorso in avanti con questo approccio. Invece, abbiamo creato una soluzione C # al 100% per implementare questi protocolli. Ciò significa che le nostre API funzioneranno ovunque sia supportato .NET Core, che sia possibile eseguire il debug con un debugger C # (tramite sourcelink) e che supporti più driver Linux sottostanti (sysfs, libgpiod e specifici della scheda). Tutto il codice è concesso in licenza come MIT. Vediamo questo approccio come un grande miglioramento per gli sviluppatori .NET rispetto a ciò che è esistito.
Vedi dotnet / iot per saperne di più. I posti migliori da cui iniziare sono campioni o dispositivi. Abbiamo creato alcuni esperimenti durante l'aggiunta del supporto per GPIO. Uno di questi stava confermando che potevamo controllare un Arduino da un Pi attraverso una connessione seriale. È stato sorprendentemente facile. Abbiamo anche trascorso molto tempo a giocare con le matrici LED, come puoi vedere in questo esempio di matrice LED RGB. Ci aspettiamo di condividere più di questi esperimenti nel tempo.
Aggiornamento dei criteri di roll-forward del runtime di .NET Core
Il runtime .NET Core, in realtà il raccoglitore di runtime, ora consente il roll-forward della versione principale come criterio di opt-in. Il raccoglitore di runtime abilita già il roll-forward su patch e versioni secondarie come criterio predefinito. Abbiamo deciso di esporre un insieme più ampio di politiche, che ci aspettavamo sarebbe stato importante per vari scenari, ma non ha modificato il comportamento di roll-forward predefinito.
Esiste una nuova proprietà chiamata RollForward, che accetta i seguenti valori:
LatestPatch: passa alla versione di patch più alta. Ciò disabilita la politica minore.
Minore: passa alla versione minore superiore più bassa, se manca la versione minore richiesta. Se è presente la versione secondaria richiesta, viene utilizzata la politica LatestPatch. Questa è la politica di default.
Maggiore: passa alla versione principale più alta più bassa e alla versione minore più bassa, se manca la versione principale richiesta. Se è presente la versione principale richiesta, viene utilizzata la politica secondaria.
LatestMinor: passa alla versione minore più alta, anche se è presente la versione minore richiesta.
LatestMajor: passa alla versione minore e maggiore minore, anche se è presente la maggiore richiesta.
Disabilita: non scorrere in avanti. Associare solo alla versione specificata. Questa politica non è consigliata per l'uso generale poiché disabilita la possibilità di eseguire il roll-forward alle patch più recenti. È consigliato solo per i test.
Vedere Comportamento di associazione runtime e dotnet / core-setup # 5691 per ulteriori informazioni.
Limiti di Docker e cgroup
Molti sviluppatori stanno impacchettando ed eseguendo la loro applicazione con contenitori. Uno scenario chiave è limitare le risorse di un contenitore come CPU o memoria. Nel 2017 abbiamo implementato il supporto per i limiti di memoria. Sfortunatamente, abbiamo scoperto che l'implementazione non era abbastanza aggressiva per rimanere in modo affidabile sotto i limiti configurati e che le applicazioni venivano ancora uccise OOM quando venivano impostati i limiti di memoria (in particolare < MB). Abbiamo risolto questo problema con .NET Core 3.0. Consigliamo vivamente agli utenti di .NET Core Docker di eseguire l'aggiornamento a .NET Core 3.0 grazie a questo miglioramento.
La funzione Limiti di risorse Docker è basata su cgroups, che è una funzionalità del kernel Linux. Dal punto di vista del runtime, dobbiamo scegliere come target le primitive di cgroup.
È possibile limitare la memoria disponibile per un contenitore con l'argomento docker run -m, come mostrato nell'esempio seguente che crea un contenitore basato su Alpine con un limite di memoria di 4 MB (e quindi stampa il limite di memoria):
Abbiamo anche aggiunto modifiche per supportare meglio i limiti della CPU (--cpus). Ciò include la modifica del modo in cui il runtime arrotonda per eccesso o per difetto per i valori decimali della CPU. Nel caso in cui --cpus sia impostato su un valore vicino (abbastanza) a un numero intero più piccolo (ad esempio, 1.499999999), il tempo di esecuzione precedentemente arrotonderebbe quel valore verso il basso (in questo caso, a 1). Di conseguenza, il runtime trarrebbe vantaggio da meno CPU di quelle richieste, portando a un sottoutilizzo della CPU. Arrotondando il valore, il runtime aumenta la pressione sullo scheduler dei thread del sistema operativo, ma anche nello scenario peggiore (--cpus = 1.000000001 - precedentemente arrotondato per difetto a 1, ora arrotondato a 2), non abbiamo osservato alcun utilizzo eccessivo di la CPU che porta al degrado delle prestazioni.
Il passo successivo è stato garantire che il pool di thread rispettasse i limiti della CPU. Parte dell'algoritmo del pool di thread è il calcolo del tempo di occupato della CPU, che è, in parte, una funzione delle CPU disponibili. Prendendo in considerazione i limiti della CPU durante il calcolo del tempo di occupato della CPU, evitiamo che varie euristiche del threadpool siano in competizione tra loro: uno che cerca di allocare più thread per aumentare il tempo di occupato della CPU e l'altro che tenta di allocare meno thread perché aggiungendo più thread non migliora il rendimento.
Riduzione delle dimensioni dell'heap GC per impostazione predefinita
Mentre lavoravamo per migliorare il supporto per i limiti della memoria docker, siamo stati ispirati a effettuare aggiornamenti più generali dei criteri GC per migliorare l'utilizzo della memoria per un set più ampio di applicazioni (anche quando non è in esecuzione in un contenitore). Le modifiche allineano meglio il budget di allocazione di generazione 0 con le moderne dimensioni della cache del processore e la gerarchia della cache.
Damian Edwards nel nostro team ha notato che l'utilizzo della memoria dei benchmark ASP.NET è stato dimezzato senza alcun effetto negativo su altre metriche delle prestazioni. È un miglioramento sbalorditivo! Come dice, questi sono i nuovi valori predefiniti, senza che sia necessario modificare il suo (o il tuo) codice (oltre all'adozione di .NET Core 3.0).
I risparmi di memoria che abbiamo riscontrato con i benchmark ASP.NET potrebbero essere o meno rappresentativi di ciò che vedrai con la tua applicazione. Ci piacerebbe sapere come queste modifiche riducono l'utilizzo della memoria per la tua applicazione.Migliore supporto per molte macchine proc
Basato sull'eredità di Windows di .NET, il GC doveva implementare il concetto di Windows di gruppi di processori per supportare macchine con 64+ processori. Questa implementazione è stata realizzata in .NET Framework, 5-10 anni fa. Con .NET Core, inizialmente abbiamo fatto la scelta per il PAL Linux di emulare lo stesso concetto, anche se non esiste in Linux. Da allora abbiamo abbandonato questo concetto nel GC e lo abbiamo trasferito esclusivamente al Windows PAL.
Il GC ora espone un interruttore di configurazione, GCHeapAffinitizeRanges, per specificare maschere di affinità su macchine con 64+ processori. Maoni Stephens ha scritto di questo cambiamento nel migliorare la configurazione della CPU per GC su macchine con> 64 CPU.
GC Supporto per pagine di grandi dimensioni
Pagine grandi o Pagine enormi è una funzione in cui il sistema operativo è in grado di stabilire aree di memoria più grandi della dimensione della pagina nativa (spesso 4K) per migliorare le prestazioni dell'applicazione che richiede queste pagine di grandi dimensioni.
Quando si verifica una traduzione dall'indirizzo da virtuale a fisico, una cache denominata Translation lookaside buffer (TLB) viene prima consultata (spesso in parallelo) per verificare se è disponibile una traduzione fisica per l'indirizzo virtuale a cui si accede, per evitare di fare un potenziale costoso passeggiata tabella-pagina. Ogni traduzione di grandi pagine utilizza un singolo buffer di traduzione all'interno della CPU. La dimensione di questo buffer è in genere tre ordini di grandezza più grande della dimensione della pagina nativa; ciò aumenta l'efficienza del buffer di traduzione, che può aumentare le prestazioni della memoria a cui si accede frequentemente. Questa vittoria può essere ancora più significativa in una macchina virtuale, che ha un TLB a due livelli.
Ora il GC può essere configurato con la funzione opt-in di GCLargePages per scegliere di allocare pagine grandi su Windows. L'uso di pagine di grandi dimensioni riduce i mancati TLB, pertanto può potenzialmente aumentare la perf dell'applicazione in generale, tuttavia, la funzione ha una propria serie di limitazioni che dovrebbero essere considerate. Bing ha sperimentato questa funzione e riscontrato miglioramenti delle prestazioni.
.NET Core Version APIs
Abbiamo migliorato le API della versione .NET Core in .NET Core 3.0. Ora restituiscono le informazioni sulla versione che ti aspetteresti. Queste modifiche, sebbene oggettivamente migliori, stanno tecnicamente rompendo e potrebbero interrompere applicazioni che si basano su API di versione esistenti per varie informazioni.
Ora puoi accedere alle seguenti informazioni sulla versione:
Miglioramenti delle pipe degli eventi
Event Pipe ora supporta più sessioni. Ciò significa che è possibile consumare eventi con EventListener in-proc e contemporaneamente avere client di pipe di eventi out-of-process.
Nuovi segnalini perf aggiunti:
- % Di tempo in GC
- Dimensione heap di generazione 0
- Dimensione heap di generazione 1
- Dimensione heap di generazione 2
- LOH Dimensione heap
- Tasso di allocazione
- Numero di assiemi caricati
- Numero di thread ThreadPool
- Tasso di contesa blocco monitor
- Coda elementi di lavoro ThreadPool
- Tasso oggetti lavoro completato ThreadPool
Il collegamento di Profiler ora è implementato utilizzando la stessa infrastruttura di Event Pipe.
Vedi Giocare con i contatori di David Fowler per avere un'idea di cosa puoi fare con la pipe degli eventi per eseguire le tue indagini sulle prestazioni o semplicemente monitorare lo stato dell'applicazione.
Vedi dotnet-counter per installare lo strumento dotnet-counter.
Supporto HTTP / 2
Ora abbiamo il supporto per HTTP / 2 in HttpClient. Il nuovo protocollo è un requisito per alcune API, come gRPC e Apple Push Notification Service. Prevediamo che più servizi richiederanno HTTP / 2 in futuro. ASP.NET ha anche il supporto per HTTP / 2.
Nota: la versione del protocollo HTTP preferita verrà negoziata tramite TLS / ALPN e HTTP / 2 verrà utilizzato solo se il server sceglie di utilizzarla.
Compilazione a più livelli
La compilazione a livelli è stata aggiunta come funzionalità di attivazione in .NET Core 2.1. È una funzione che consente al runtime di utilizzare in modo più adattivo il compilatore Just-In-Time (JIT) per ottenere prestazioni migliori, sia all'avvio che per massimizzare il throughput. È abilitato per impostazione predefinita con .NET Core 3.0. Nell'ultimo anno abbiamo apportato molti miglioramenti alla funzionalità, incluso il test con una varietà di carichi di lavoro, inclusi siti Web, PowerShell Core e app desktop Windows. Le prestazioni sono molto migliori, il che è ciò che ci ha permesso di abilitarlo di default.
Miglioramenti IEEE in virgola mobile
Le APIs in virgola mobile sono state aggiornate per essere conformi alla revisione IEEE 754-2008. L'obiettivo del progetto .NET Core in virgola mobile è quello di esporre tutte le operazioni "richieste" e garantire che siano comportamentalmente conformi alle specifiche IEEE.
Correzioni di analisi e formattazione:
- Analizzare correttamente e arrotondare input di qualsiasi lunghezza.
- Analizzare e formattare correttamente zero negativo.
- Analizzare correttamente Infinity e NaN eseguendo un controllo senza distinzione tra maiuscole e minuscole e consentendo un precedente + facoltativo, ove applicabile.
Nuove APIs matematiche:
BitIncrement / BitDecrement: corrisponde alle operazioni IEEE nextUp e nextDown. Restituiscono il più piccolo numero in virgola mobile che confronta maggiore o minore dell'input (rispettivamente). Ad esempio, Math.BitIncrement (0.0) restituisce double.Epsilon.
MaxMagnitude / MinMagnitude - corrisponde alle operazioni IEEE maxNumMag e minNumMag, restituiscono il valore maggiore o minore in grandezza dei due ingressi (rispettivamente). Ad esempio, Math.MaxMagnitude (2.0, -3.0) restituisce -3.0.
ILogB - corrisponde all'operazione IEEE logB che restituisce un valore integrale, restituisce il registro integrale base-2 del parametro di input. Questo è effettivamente lo stesso di floor (log2 (x)), ma fatto con un errore di arrotondamento minimo.
Scala B: corrisponde all'operazione IEEE di scala B che assume un valore integrale, restituisce effettivamente x * pow (2, n), ma viene eseguita con un errore di arrotondamento minimo.
Log2: corrisponde all'operazione IEEE log2, restituisce il logaritmo in base 2. Riduce al minimo l'errore di arrotondamento.
FusedMultiplyAdd: corrisponde all'operazione IEEE fma, esegue un'aggiunta moltiplicata fusa. Cioè, fa (x * y) + z come una singola operazione, riducendo al minimo l'errore di arrotondamento. Un esempio potrebbe essere FusedMultiplyAdd (1e308, 2.0, -1e308) che restituisce 1e308. Il normale (1e308 * 2.0) - 1e308 restituisce double.PositiveInfinity.
CopySign: corrisponde all'operazione IEEE copySign, restituisce il valore di x, ma con il segno di y.
Intrinsics dipendenti dalla piattaforma .NET
Abbiamo aggiunto API che consentono l'accesso a determinate istruzioni della CPU orientate alle prestazioni, come il SIMD o i set di istruzioni di manipolazione dei bit. Queste istruzioni possono aiutare a ottenere grandi miglioramenti delle prestazioni in determinati scenari, come l'elaborazione efficiente dei dati in parallelo. Oltre a esporre le API da utilizzare per i tuoi programmi, abbiamo iniziato a utilizzare queste istruzioni per accelerare anche le librerie .NET.
I seguenti PR CoreCLR dimostrano alcuni aspetti intrinseci, sia mediante l'implementazione che l'uso:
Implementare semplici intrinseci hardware SSE2
Implementare le intrinseche hardware SSE
Arm64 Base HW Intrinsics
Usa TZCNT e LZCNT per Individua {Primo | Ultimo} Trovato {Byte | Char}
Per ulteriori informazioni, dai un'occhiata a .NET Platform Dependent Intrinsics, che definisce un approccio per la definizione di questa infrastruttura hardware, consentendo a Microsoft, ai fornitori di chip o a qualsiasi altra società o individuo di definire API hardware / chip che dovrebbero essere esposte al codice .NET.
Supporting TLS 1.3 and OpenSSL 1.1.1 now Supported on Linux
NET Core ora può usufruire del supporto TLS 1.3 in OpenSSL 1.1.1. I vantaggi di TLS 1.3 sono molteplici, per il team OpenSSL:
Tempi di connessione migliorati grazie alla riduzione del numero di round trip richiesti tra client e server
Maggiore sicurezza grazie alla rimozione di vari algoritmi crittografici obsoleti e non sicuri e alla crittografia di più handshake della connessione
.NET Core 3.0 è in grado di utilizzare OpenSSL 1.1.1, OpenSSL 1.1.0 o OpenSSL 1.0.2 (qualunque sia la migliore versione trovata, su un sistema Linux). Quando OpenSSL 1.1.1 è disponibile, i tipi SslStream e HttpClient utilizzeranno TLS 1.3 quando si utilizzano SslProtocols.None (protocolli predefiniti di sistema), supponendo che il client e il server supportino TLS 1.3.
.NET Core supporterà TLS 1.3 su Windows e macOS - ci aspettiamo automaticamente - quando il supporto sarà disponibile.
Crittografia
Abbiamo aggiunto il supporto per le cifre AES-GCM e AES-CCM, implementate tramite System.Security.Cryptography.AesGcm e System.Security.Cryptography.AesCcm. Questi algoritmi sono entrambi algoritmi Authenticated Encryption with Association Data (AEAD) e i primi algoritmi Authenticated Encryption (AE) aggiunti a .NET Core.
NET Core 3.0 ora supporta l'importazione e l'esportazione di chiavi pubbliche e private asimmetriche da formati standard, senza la necessità di utilizzare un certificato X.509.
Tutti i tipi di chiave (RSA, DSA, ECDsa, ECDiffieHellman) supportano il formato X.509 SubjectPublicKeyInfo per le chiavi pubbliche e i formati PKCS # 8 PrivateKeyInfo e PKCS # 8 EncryptedPrivateKeyInfo per le chiavi private. RSA supporta inoltre PKCS # 1 RSAPublicKey e PKCS # 1 RSAPrivateKey. Tutti i metodi di esportazione producono dati binari con codifica DER e i metodi di importazione prevedono lo stesso; se una chiave è memorizzata nel formato PEM di testo, il chiamante dovrà decodificare base64 il contenuto prima di chiamare un metodo di importazione.
I file PKCS # 8 possono essere controllati con la classe System.Security.Cryptography.Pkcs.Pkcs8PrivateKeyInfo.
I file PFX / PKCS # 12 possono essere ispezionati e manipolati con System.Security.Cryptography.Pkcs.Pkcs12Info e System.Security.Cryptography.Pkcs.Pkcs12Builder, rispettivamente.
New Japanese Era (Reiwa)
Il 1 ° maggio 2019, il Giappone ha iniziato una nuova era chiamata Reiwa. Il software che supporta i calendari giapponesi, come .NET Core, deve essere aggiornato per adattarsi a Reiwa. .NET Core e .NET Framework sono stati aggiornati e gestiscono correttamente la formattazione e l'analisi delle date giapponesi con la nuova era.
.NET si affida al sistema operativo o ad altri aggiornamenti per elaborare correttamente le date di Reiwa. Se tu o i tuoi clienti utilizzate Windows, scaricate gli ultimi aggiornamenti per la vostra versione di Windows. Se esegui macOS o Linux, scarica e installa la ICU versione 64.2, che supporta la nuova era giapponese.
La gestione di una nuova era nel calendario giapponese nel blog .NET contiene ulteriori informazioni sul supporto .NET per la nuova era giapponese.
Miglioramenti al contesto del carico di assemblaggio
Miglioramenti a AssemblyLoadContext:
Abilita contesti di denominazione
Aggiunta la possibilità di enumerare gli ALC
Aggiunta la possibilità di enumerare gli assembly all'interno di un ALC
Ha reso concreto il tipo - quindi l'istanza è più semplice (nessun requisito per tipi personalizzati per scenari semplici)
Vedi dotnet / corefx # 34791 per maggiori dettagli. L'esempio appwithalc dimostra queste nuove funzionalità.
Utilizzando AssemblyDependencyResolver insieme a un AssemblyLoadContext personalizzato, un'applicazione può caricare plug-in in modo che le dipendenze di ciascun plug-in vengano caricate dalla posizione corretta e le dipendenze di un plug-in non entrino in conflitto con un'altra. L'esempio AppWithPlugin include plug-in con dipendenze in conflitto e plug-in che si basano su assembly satellite o librerie native.
Scaricabilità dell'assemblaggio
La scaricabilità degli assembly è una nuova funzionalità di AssemblyLoadContext. Questa nuova funzionalità è in gran parte trasparente dal punto di vista dell'API, esposta con solo alcune nuove API. Consente di scaricare un contesto di caricatore, liberando tutta la memoria per tipi istanziati, campi statici e per l'assemblaggio stesso. Un'applicazione dovrebbe essere in grado di caricare e scaricare gli assembly tramite questo meccanismo per sempre senza subire perdite di memoria.
Prevediamo che questa nuova funzionalità verrà utilizzata per i seguenti scenari:
Scenari di plug-in in cui sono richiesti caricamento e scaricamento di plug-in dinamici.
Compilare, eseguire e quindi scaricare il codice in modo dinamico. Utile per siti Web, motori di scripting, ecc.
Il caricamento di assembly per introspezione (come ReflectionOnlyLoad), sebbene MetadataLoadContext sarà una scelta migliore in molti casi.
Assembly Metadata Reading with MetadataLoadContext
Abbiamo aggiunto MetadataLoadContext, che consente la lettura dei metadati dell'assembly senza influire sul dominio dell'applicazione del chiamante. Gli assembly vengono letti come dati, inclusi assembly creati per architetture e piattaforme diverse rispetto all'attuale ambiente di runtime. MetadataLoadContext si sovrappone al tipo ReflectionOnlyLoad, disponibile solo in .NET Framework.
MetdataLoadContext è disponibile nel pacchetto System.Reflection.MetadataLoadContext. È un pacchetto .NET Standard 2.0.
Gli scenari per MetadataLoadContext includono funzioni in fase di progettazione, strumenti in fase di creazione e funzioni di illuminazione in fase di runtime che devono ispezionare un insieme di assiemi come dati e liberare tutti i blocchi di file e la memoria dopo l'esecuzione dell'ispezione.
Esempio di hosting nativo
Il team ha pubblicato un campione di hosting nativo. Dimostra un approccio di best practice per l'hosting di .NET Core in un'applicazione nativa.
Come parte di .NET Core 3.0, ora esponiamo le funzionalità generali agli host nativi .NET Core che in precedenza erano disponibili solo per le applicazioni gestite .NET Core tramite gli host .NET Core forniti ufficialmente. La funzionalità è principalmente correlata al caricamento dell'assieme. Questa funzionalità dovrebbe facilitare la produzione di host nativi in ??grado di sfruttare il set completo di funzionalità di .NET Core.
Altri miglioramenti API
Abbiamo ottimizzato Span>T<, Memoria >T< e tipi correlati introdotti in .NET Core 2.1. Operazioni comuni come costruzione di span, slicing, analisi e formattazione ora funzionano meglio. Inoltre, tipi come String hanno visto miglioramenti sotto copertura per renderli più efficienti se usati come chiavi con Dictionary<TKey, TValue> e altre raccolte. Non sono necessarie modifiche al codice per usufruire di questi miglioramenti.
Anche i seguenti miglioramenti sono nuovi:
- Brotli support built-in to HttpClient
- ThreadPool.UnsafeQueueWorkItem(IThreadPoolWorkItem)
- Unsafe.Unbox
- CancellationToken.Unregister
- Complex arithmetic operators
- Socket APIs for TCP keep alive
- StringBuilder.GetChunks
- IPEndPoint parsing
- RandomNumberGenerator.GetInt32
- System.Buffers.SequenceReader
Le applicazioni ora hanno eseguibili nativi per impostazione predefinita
Le applicazioni .NET Core sono ora costruite con eseguibili nativi. Questo è nuovo per l'applicazione dipendente dal framework. Fino ad ora, solo le applicazioni autonome avevano eseguibili.
Puoi aspettarti le stesse cose con questi eseguibili come faresti con altri eseguibili nativi, come:
È possibile fare doppio clic sul file eseguibile per avviare l'applicazione.
Puoi avviare l'applicazione da un prompt dei comandi, utilizzando myapp.exe, su Windows e ./myapp, su Linux e macOS.
L'eseguibile generato come parte della build corrisponderà al sistema operativo e alla CPU. Ad esempio, se ci si trova su una macchina x64 Linux, l'eseguibile funzionerà solo su quel tipo di macchina, non su una macchina Windows e non su una macchina ARM Linux. Questo perché gli eseguibili sono codice nativo (proprio come C ++). Se si desidera targetizzare un altro tipo di macchina, è necessario pubblicare con un argomento di runtime. Puoi continuare ad avviare applicazioni con il comando dotnet e non utilizzare eseguibili nativi, se preferisci.
Ottimizza le tue app .NET Core con le immagini ReadyToRun
È possibile migliorare i tempi di avvio dell'applicazione .NET Core compilando gli assembly dell'applicazione in formato ReadyToRun (R2R). R2R è una forma di compilazione anticipata (AOT). È una funzionalità opt-in al momento della pubblicazione in .NET Core 3.0.
I binari R2R migliorano le prestazioni di avvio riducendo la quantità di lavoro che JIT deve fare durante il caricamento dell'applicazione. I binari contengono un codice nativo simile a quello che la JIT produrrebbe, dando alla JIT un po 'di ferie quando le prestazioni contano di più (all'avvio). I binari R2R sono più grandi perché contengono sia il codice di linguaggio intermedio (IL), che è ancora necessario per alcuni scenari, sia la versione nativa dello stesso codice, per migliorare l'avvio.
Per abilitare la compilazione ReadyToRun:
- Impostare la proprietà PublishReadyToRun su true.
- Pubblica utilizzando un RuntimeIdentifier esplicito.
Nota: quando gli assembly dell'applicazione vengono compilati, il codice nativo prodotto è specifico della piattaforma e dell'architettura (motivo per cui è necessario specificare un RuntimeIdentifier valido durante la pubblicazione).
ecco un esempio:
E pubblica usando il seguente comando:
Nota: RuntimeIdentifier può essere impostato su un altro sistema operativo o chip. Può anche essere impostato nel file di progetto.
Collegamento di assemblaggio
.NET core 3.0 SDK viene fornito con uno strumento in grado di ridurre le dimensioni delle app analizzando IL e tagliando assiemi inutilizzati. È un'altra funzionalità di opt-in al momento della pubblicazione in .NET Core 3.0.
Con .NET Core, è sempre stato possibile pubblicare app autonome che includono tutto il necessario per eseguire il codice, senza richiedere l'installazione di .NET sulla destinazione di distribuzione. In alcuni casi, l'app richiede solo un piccolo sottoinsieme del framework per funzionare e potrebbe essere potenzialmente molto più piccola includendo solo le librerie utilizzate.
Usiamo il linker IL per scansionare l'IL della tua applicazione per rilevare quale codice è effettivamente richiesto e quindi tagliare le librerie di framework non utilizzate. Ciò può ridurre significativamente le dimensioni di alcune app. In genere, le app per console simili a strumenti di piccole dimensioni traggono il massimo vantaggio in quanto tendono a utilizzare sottoinsiemi piuttosto piccoli del framework e sono generalmente più suscettibili di taglio.
Per utilizzare il linker:
Impostare la proprietà PublishTrimmed su true.
Pubblica utilizzando un RuntimeIdentifier esplicito.
Ecco un esempio:
E pubblica usando il seguente comando:
Nota: RuntimeIdentifier può essere impostato su un altro sistema operativo o chip. Può anche essere impostato nel file di progetto.
Vedere Bundler di file singolo per ulteriori informazioni.
Il trimmer di assemblaggio, la compilazione anticipata (tramite crossgen) e il raggruppamento di singoli file sono tutte nuove funzionalità di .NET Core 3.0 che possono essere utilizzate insieme o separatamente.
Ci aspettiamo che alcuni di voi preferiscano il single exe fornito da un compilatore anticipato, rispetto all'approccio autoestraente-eseguibile che stiamo fornendo in .NET Core 3.0. L'approccio del compilatore anticipato verrà fornito come parte della versione .NET 5.
dotnet build ora copia le dipendenze
dotnet build ora copia le dipendenze NuGet per l'applicazione dalla cache NuGet nella cartella di output della build durante l'operazione di build. Fino a questa versione, tali dipendenze venivano copiate solo come parte della pubblicazione dotnet. Questa modifica consente di copiare l'output di generazione su macchine diverse.
Ci sono alcune operazioni, come il collegamento e la pubblicazione di pagine di rasoio che richiedono la pubblicazione.
.NET Core Tools - installazione locale
Gli strumenti .NET Core sono stati aggiornati per consentire l'installazione locale. Hanno vantaggi rispetto agli strumenti globali, che sono stati aggiunti in .NET Core 2.1.
L'installazione locale consente quanto segue:
- Limitare l'ambito di utilizzo di uno strumento.
- Utilizzare sempre una versione specifica dello strumento, che potrebbe differire da uno strumento installato a livello globale o da un'altra installazione locale. Questo si basa sulla versione nel file manifest degli strumenti locali.
- Lanciato con dotnet, come in dotnet mytool.
Nota: consultare la documentazione di anteprima anticipata degli strumenti locali per ulteriori informazioni.
I programmi di installazione di .NET Core SDK ora eseguiranno l'aggiornamento sul posto
I programmi di installazione MSI .NET Core SDK per Windows inizieranno ad aggiornare le versioni delle patch in atto. Ciò ridurrà il numero di SDK installati su macchine sviluppatore e di produzione.
La politica di aggiornamento si rivolge specificamente alle bande di funzionalità SDK .NET Core. Le bande di caratteristiche sono definite in centinaia di gruppi nella sezione patch del numero di versione. Ad esempio, 3.0.101 e 3.0.201 sono versioni in due diverse bande di caratteristiche mentre 3.0.101 e 3.0.199 sono nella stessa serie di caratteristiche.
Ciò significa che quando .NET Core SDK 3.0.101 diventa disponibile ed è installato, .NET Core SDK 3.0.100 verrà rimosso dalla macchina se esiste. Quando .NET Core SDK 3.0.200 diventa disponibile e viene installato sullo stesso computer, .NET Core SDK 3.0.101 non verrà rimosso. In tale situazione, .NET Core SDK 3.0.200 verrà comunque utilizzato per impostazione predefinita, ma .NET Core SDK 3.0.101 (o versioni successive .1xx) sarà comunque utilizzabile se è configurato per l'uso tramite global.json.
Questo approccio è in linea con il comportamento di global.json, che consente il roll forward tra le versioni di patch, ma non le bande di caratteristiche dell'SDK. Pertanto, l'aggiornamento tramite il programma di installazione dell'SDK non comporta errori dovuti a un SDK mancante. Le bande di funzionalità si allineano anche con installazioni di Visual Studio affiancate per quegli utenti che installano SDK per l'utilizzo di Visual Studio.
Per ulteriori informazioni, consultare:
Miglioramenti alle dimensioni di .NET Core SDK
.NET Core SDK è notevolmente più piccolo con .NET Core 3.0. Il motivo principale è che abbiamo cambiato il modo in cui costruiamo l'SDK, passando a "pacchetti" appositamente costruiti di vario tipo (assiemi di riferimento, framework, template). Nelle versioni precedenti (incluso .NET Core 2.2), abbiamo creato l'SDK dai pacchetti NuGet, che includeva molti artefatti che non erano richiesti e che sprecavano molto spazio.
Dimensione SDK .NET Core 3.0 (modifica della dimensione tra parentesi)
Dimensioni del programma di installazione del sistema operativo (modifica) Dimensioni su disco (modifica)
Windows 164 MB (-440 KB; 0%) 441 MB (-968 MB; -68,7%)
Linux 115 MB (-55 MB; -32%) 332 MB (-1068 MB; -76,2%)
macOS 118 MB (-51 MB; -30%) 337 MB (-1063 MB; -75,9%)
I miglioramenti delle dimensioni per Linux e macOS sono notevoli. Il miglioramento per Windows è minore perché abbiamo aggiunto WPF e Windows Form come parte di .NET Core 3.0. È sorprendente che abbiamo aggiunto WPF e Windows Form in 3.0 e che il programma di installazione sia ancora (un po ') più piccolo.
Puoi vedere lo stesso vantaggio con le immagini Docker di .NET Core SDK (qui, limitate a Debian e Alpine x64).
Distro 2.2 Dimensione 3.0 Dimensione
Debian 1.74GB 706MB
Alpine 1.48GB 422MB
Puoi vedere come abbiamo calcolato queste dimensioni di file in Miglioramenti alle dimensioni dell'SDK di .NET Core 3.0. Vengono fornite istruzioni dettagliate in modo da poter eseguire gli stessi test nel proprio ambiente.
Aggiornamento sulla pubblicazione Docker
I team di Microsoft stanno ora pubblicando le immagini dei container nel Microsoft
Container Registry (MCR). Esistono due ragioni principali per questa modifica:
- Condividi le immagini dei container fornite da Microsoft in più registri, come Docker Hub e Red Hat.
- Utilizzare Microsoft Azure come CDN globale per la consegna di immagini contenitore fornite da Microsoft.
Nel team .NET stiamo ora pubblicando tutte le immagini .NET Core su MCR. Come puoi vedere dai link (se fai clic su di esso), continuiamo ad avere "home page" su Docker Hub. Intendiamo che ciò continui indefinitamente. MCR non offre tali pagine, ma si affida a registri pubblici, come Docker Hub, per fornire agli utenti informazioni relative alle immagini.
I collegamenti ai nostri vecchi repository, come microsoft / dotnet e microsoft / dotnet-nightly, vengono ora inviati alle nuove posizioni. Le immagini esistenti in tali posizioni esistono ancora e non verranno eliminate.
Continueremo a riparare i tag mobili nei vecchi repository per la durata supportata delle varie versioni di .NET Core. Ad esempio, 2.1-sdk, 2.2-runtime e gli ultimi sono esempi di tag mobili che verranno serviti. Un tag di versione in tre parti come 2.1.2-sdk non verrà revisionato, come già avveniva. Supporteremo solo immagini .NET Core 3.0 in MCR.
Ad esempio, la stringa di tag corretta per estrarre l'immagine SDK 3.0 ora è simile alla seguente:
La nuova stringa MCR verrà utilizzata con entrambe le istruzioni Docker pull e Dockerfile FROM.
Vedi .NET Core Immagini ora disponibili tramite Microsoft Container Registry per ulteriori informazioni.
Le immagini Docker dell'SDK contengono PowerShell Core
PowerShell Core è stato aggiunto alle immagini del contenitore Docker SDK .NET Core, per richieste della community. PowerShell Core è uno strumento / framework di automazione e configurazione multipiattaforma (Windows, Linux e macOS) che funziona bene con gli strumenti esistenti ed è ottimizzato per gestire dati strutturati (ad es. JSON, CSV, XML, ecc.), API REST e modelli di oggetti. Include una shell della riga di comando, un linguaggio di scripting associato e un framework per l'elaborazione dei cmdlet.
È possibile provare PowerShell Core, come parte dell'immagine del contenitore .NET Core SDK, eseguendo il seguente comando Docker:
Esistono due scenari principali che consente di avere PowerShell nell'immagine del contenitore .NET Core SDK, che altrimenti non sarebbero stati possibili:
Scrivi Dockerfile dell'applicazione .NET Core con sintassi PowerShell per qualsiasi sistema operativo.
Scrivi una logica di build dell'applicazione / libreria .NET Core che può essere facilmente containerizzata.
Sintassi di esempio per l'avvio di PowerShell per una build containerizzata (montata sul volume):
docker run -it -v c: \ myrepo: / myrepo -w / myrepo mcr.microsoft.com/dotnet/core/sdk:3.0 pwsh build.ps1
docker run -it -v c: \ myrepo: / myrepo -w / myrepo mcr.microsoft.com/dotnet/core/sdk:3.0 ./build.ps1
Affinché il secondo esempio funzioni, su Linux, il file .ps1 deve avere il modello seguente e deve essere formattato con terminazioni di linea Unix (LF) e Windows (CRLF):
Se non conosci PowerShell e desideri saperne di più, ti consigliamo di consultare la documentazione introduttiva.
Nota: PowerShell Core è ora disponibile come parte delle immagini del contenitore SDK .NET Core 3.0. Non fa parte di .NET Core 3.0 SDK.
Supporto per Red Hat
Nell'aprile 2015, abbiamo annunciato che .NET Core sarebbe arrivato a Red Hat Enterprise Linux. Attraverso un'eccellente partnership di ingegneria con Red Hat, .NET Core 1.0 è apparso come componente disponibile nelle raccolte di software Red Hat, giugno 2016. Lavorando con gli ingegneri di Red Hat, abbiamo imparato (e continuiamo a imparare!) Molto sul rilascio di software per la comunità Linux.
Negli ultimi quattro anni, Red Hat ha distribuito molti aggiornamenti .NET Core e versioni significative, come 2.1 e 2.2, lo stesso giorno di Microsoft. Con .NET Core 2.2, Red Hat ha ampliato le proprie offerte .NET Core per includere piattaforme OpenShift. Con il rilascio di RHEL 8, siamo entusiasti di avere .NET Core 2.1 e presto, 3.0, disponibile in Red Hat Application Streams.
Chiusura
.NET Core 3.0 è una nuova importante versione di .NET Core e include una vasta serie di miglioramenti. Ti consigliamo di iniziare ad adottare .NET Core 3.0 il prima possibile. Migliora notevolmente .NET Core in molti modi, come l'enorme riduzione delle dimensioni dell'SDK e migliorando notevolmente il supporto per scenari chiave come contenitori e applicazioni desktop di Windows. Ci sono anche molti piccoli miglioramenti che non sono stati inclusi in questo post, di cui sicuramente beneficerai nel tempo.
Per favore condividi il tuo feedback con noi, nei prossimi giorni, settimane o mesi. Speriamo che vi piaccia. Ci siamo divertiti molto a farlo per te.
Se vuoi ancora leggere di più, ti consigliamo di leggere i seguenti post recenti: