Condividi tramite

Novità di .NET Core 2.2

.NET Core 2.2 include miglioramenti nella distribuzione delle applicazioni, nella gestione degli eventi per i servizi di runtime, nell'autenticazione nei database SQL di Azure, nelle prestazioni del compilatore JIT e nell'inserimento del codice prima dell'esecuzione del Main metodo.

Nuova modalità di distribuzione

A partire da .NET Core 2.2, è possibile distribuire file eseguibili dipendenti dal framework, che sono file.exe anziché .dll file. In modo funzionale simile alle distribuzioni dipendenti dal framework, gli eseguibili dipendenti dal framework (FDE) si basano ancora sulla presenza di una versione condivisa a livello di sistema di .NET Core da eseguire. L'app contiene solo il tuo codice ed eventuali dipendenze di terze parti. A differenza delle distribuzioni dipendenti dal framework, le IDE sono specifiche della piattaforma.

Questa nuova modalità di distribuzione ha il vantaggio di creare un eseguibile invece di una libreria, il che significa che è possibile eseguire l'app direttamente senza richiamare dotnet prima.

Nucleo

Gestione degli eventi nei servizi di runtime

Spesso è consigliabile monitorare l'uso dell'applicazione di servizi di runtime, ad esempio GC, JIT e ThreadPool, per comprendere come influiscono sull'applicazione. Nei sistemi Windows, questa operazione viene in genere eseguita monitorando gli eventi ETW del processo corrente. Anche se continua a funzionare correttamente, non è sempre possibile usare ETW se si esegue in un ambiente con privilegi limitati o in Linux o macOS.

A partire da .NET Core 2.2, gli eventi CoreCLR possono ora essere utilizzati usando la System.Diagnostics.Tracing.EventListener classe . Questi eventi descrivono il comportamento di tali servizi di runtime come GC, JIT, ThreadPool e interoperabilità. Si tratta degli stessi eventi che sono esposti come parte del provider ETW di CoreCLR.  Ciò consente alle applicazioni di utilizzare questi eventi o di usare un meccanismo di trasporto per inviarli a un servizio di aggregazione di telemetria. È possibile vedere come sottoscrivere gli eventi nell'esempio di codice seguente:

internal sealed class SimpleEventListener : EventListener
{
    // Called whenever an EventSource is created.
    protected override void OnEventSourceCreated(EventSource eventSource)
    {
        // Watch for the .NET runtime EventSource and enable all of its events.
        if (eventSource.Name.Equals("Microsoft-Windows-DotNETRuntime"))
        {
            EnableEvents(eventSource, EventLevel.Verbose, (EventKeywords)(-1));
        }
    }

    // Called whenever an event is written.
    protected override void OnEventWritten(EventWrittenEventArgs eventData)
    {
        // Write the contents of the event to the console.
        Console.WriteLine($"ThreadID = {eventData.OSThreadId} ID = {eventData.EventId} Name = {eventData.EventName}");
        for (int i = 0; i < eventData.Payload.Count; i++)
        {
            string payloadString = eventData.Payload[i]?.ToString() ?? string.Empty;
            Console.WriteLine($"\tName = \"{eventData.PayloadNames[i]}\" Value = \"{payloadString}\"");
        }
        Console.WriteLine("\n");
    }
}

.NET Core 2.2 aggiunge inoltre le due proprietà seguenti alla EventWrittenEventArgs classe per fornire informazioni aggiuntive sugli eventi ETW:

Dati

Autenticazione di AAD nei database SQL di Azure con la proprietà SqlConnection.AccessToken

A partire da .NET Core 2.2, è possibile usare un token di accesso rilasciato da Azure Active Directory per l'autenticazione in un database SQL di Azure. Per supportare i token di accesso, la AccessToken proprietà è stata aggiunta alla SqlConnection classe . Per sfruttare i vantaggi dell'autenticazione AAD, scaricare la versione 4.6 del pacchetto NuGet System.Data.SqlClient. Per usare la funzionalità, è possibile ottenere il valore del token di accesso usando Active Directory Authentication Library per .NET contenuto nel Microsoft.IdentityModel.Clients.ActiveDirectory pacchetto NuGet.

Miglioramenti del compilatore JIT

La compilazione a livelli rimane una funzionalità di consenso esplicito

In .NET Core 2.1, il compilatore JIT ha implementato una nuova tecnologia del compilatore, la compilazione a livelli, come funzionalità di consenso esplicito. L'obiettivo della compilazione a livelli è migliorare le prestazioni. Una delle attività importanti eseguite dal compilatore JIT è l'ottimizzazione dell'esecuzione del codice. Per i percorsi di codice poco usati, tuttavia, il compilatore può dedicare più tempo all'ottimizzazione del codice rispetto al tempo trascorso dal runtime per l'esecuzione di codice non ottimizzato. La compilazione a livelli introduce due fasi nella compilazione JIT:

  • Un primo livello, che genera il codice il più rapidamente possibile.
  • Secondo livello, che genera codice ottimizzato per i metodi eseguiti di frequente. Il secondo livello di compilazione viene eseguito in parallelo per migliorare le prestazioni.

Per informazioni sul miglioramento delle prestazioni che può derivare dalla compilazione a livelli, vedere Annuncio di .NET Core 2.2 Preview 2.

Per informazioni sul consenso esplicito alla compilazione a livelli, vedere Miglioramenti del compilatore Jit in Novità di .NET Core 2.1.

Tempo di esecuzione

Inserimento di codice prima dell'esecuzione del metodo Main

A partire da .NET Core 2.2, è possibile usare un hook di avvio per inserire il codice prima di eseguire il metodo Main di un'applicazione. Gli hook di avvio consentono a un host di personalizzare il comportamento delle applicazioni dopo la distribuzione senza dover ricompilare o modificare l'applicazione.

Si prevede che i provider di hosting definiscino la configurazione e i criteri personalizzati, incluse le impostazioni che potenzialmente influenzano il comportamento di carico del punto di ingresso principale, ad esempio il System.Runtime.Loader.AssemblyLoadContext comportamento. L'hook può essere usato per configurare la traccia o l'inserimento dei dati di telemetria, per configurare i callback per la gestione o per definire altri comportamenti dipendenti dall'ambiente. L'hook è separato dal punto di ingresso, in modo che il codice utente non debba essere modificato.

Per ulteriori informazioni, consulta Hook di avvio dell'host.

Vedere anche