Leggere in inglese

Condividi tramite


Novità di .NET Framework

Nota

.NET Framework viene gestito indipendentemente dagli aggiornamenti di Windows con correzioni di bug di sicurezza e affidabilità. In generale, gli aggiornamenti della sicurezza vengono rilasciati trimestralmente. .NET Framework continuerà a essere incluso in Windows, senza piani per rimuoverlo. Non è necessario eseguire la migrazione delle app .NET Framework, ma per il nuovo sviluppo usare .NET 8 o versione successiva.

Questo articolo riepiloga le nuove funzionalità e i miglioramenti principali nelle versioni seguenti di .NET Framework:

Questo articolo non fornisce informazioni complete su ogni nuova funzionalità ed è soggetto a modifiche. Per informazioni generali su .NET Framework, vedere Introduzione. Per le piattaforme supportate, vedere Requisiti di sistema. Per i collegamenti di download e le istruzioni di installazione, vedere Guida all'installazione.

Nota

Il team di .NET Framework rilascia anche funzionalità fuori banda, usando NuGet, per espandere il supporto della piattaforma e introdurre nuove funzionalità, ad esempio raccolte non modificabili e tipi di vettore abilitati per SIMD. Per altre informazioni, vedere librerie di classi e API aggiuntive e .NET Framework e versioni fuori banda. Consulta un elenco completo dei pacchetti NuGet per .NET Framework.

Introduzione a .NET Framework 4.8.1

.NET Framework 4.8.1 si basa sulle versioni precedenti di .NET Framework 4.x aggiungendo molte nuove correzioni e diverse nuove funzionalità, pur rimanendo un prodotto molto stabile.

Scaricare e installare .NET Framework 4.8.1

È possibile scaricare .NET Framework 4.8.1 dai percorsi seguenti:

.NET Framework 4.8 può essere installato in Windows 11, Windows 10 versione 21H2, Windows 10 versione 21H1, Windows 10 versione 20H2 e le piattaforme server corrispondenti a partire da Windows Server 2022. È possibile installare .NET Framework 4.8.1 usando il programma di installazione Web o il programma di installazione offline. Il modo consigliato per la maggior parte degli utenti consiste nell'usare il programma di installazione Web.

È possibile usare .NET Framework 4.8.1 in Visual Studio 2022 17.3 o versione successiva installando .NET Framework 4.8.1 Developer Pack.

Novità di .NET Framework 4.8.1

.NET Framework 4.8.1 introduce nuove funzionalità nelle aree seguenti:

L'accessibilità migliorata, che consente a un'applicazione di offrire un'esperienza appropriata per gli utenti di Assistive Technology, è un obiettivo importante di .NET Framework 4.8.1. Per informazioni sui miglioramenti dell'accessibilità in .NET Framework 4.8.1, vedere Novità dell'accessibilità in .NET Framework.

.NET Framework 4.8.1 aggiunge il supporto arm64 nativo alla famiglia .NET Framework. Pertanto, gli investimenti nell'ampio ecosistema di app e librerie di .NET Framework possono ora sfruttare i vantaggi dell'esecuzione di carichi di lavoro in modo nativo in Arm64, ovvero prestazioni migliori rispetto all'esecuzione di codice x64 emulato in Arm64.

Microsoft si impegna a fornire prodotti e piattaforme accessibili a tutti. .NET Framework 4.8.1 offre due piattaforme di sviluppo dell'interfaccia utente di Windows, entrambe che forniscono agli sviluppatori il supporto necessario per creare applicazioni accessibili. Nelle ultime versioni, sia Windows Form che WPF hanno aggiunto nuove funzionalità e sono stati risolti numerosi problemi di affidabilità correlati all'accessibilità. Per altre informazioni sui problemi risolti o aggiunti in ogni versione, vedere Novità dell'accessibilità in .NET Framework.

In questa versione, sia Windows Forms che WPF hanno apportato miglioramenti alla gestione delle descrizioni comando per renderle più accessibili. In entrambi i casi, le descrizioni comando sono ora conformi alle linee guida indicate nei contenuti WCAG2.1 relativi alle indicazioni su Hover o Focus. I requisiti per le descrizioni comando sono:

  • Le descrizioni comando devono essere visualizzate tramite il passaggio del mouse o tramite lo spostamento tramite tastiera al controllo.
  • Le descrizioni comando devono essere ignorate. Ovvero, un semplice comando da tastiera come esc dovrebbe ignorare la descrizione comando.
  • Le descrizioni comando devono essere interattive al passaggio del mouse. Gli utenti dovrebbero poter posizionare il cursore del mouse sul tooltip. In questo modo, è possibile usare la lente di ingrandimento per consentire agli utenti con ipovedenza di leggere la descrizione comando.
  • Le descrizioni comando devono essere persistenti. Le descrizioni comando non dovrebbero scomparire automaticamente dopo un determinato periodo di tempo. Invece, le descrizioni comando devono essere eliminate facendo spostare il mouse dall'utente su un altro controllo o tramite un comando da tastiera.

In Windows Form questo supporto è disponibile solo nei sistemi operativi Windows 11 o versioni successive. Windows Forms è un involucro gestito leggero attorno alle API di Windows e il nuovo comportamento del tooltip è diventato disponibile solo in Windows 11. WPF non ha dipendenze di versione del sistema operativo per le descrizioni comando accessibili.

WPF ha implementato la maggior parte dei requisiti per le descrizioni comando conformi a WCAG2.1 in .NET Framework 4.8. In questa versione, WPF ha migliorato l'esperienza assicurandosi che un tooltip nella finestra corrente possa essere facilmente chiuso usando il tasto ESC , il tasto CTRL (da solo) o tramite la combinazione CTRLMAIUSCF10. L'ambito della chiave di escape è stato ridotto in questa versione per essere applicato solo alla finestra corrente. In precedenza si applicava a qualsiasi tooltip aperto nell'applicazione.

Windows Form è stato il primo stack dell'interfaccia utente di Windows creato per .NET Framework. Di conseguenza, è stato originariamente creato per utilizzare la tecnologia di accessibilità ereditata, che non soddisfa i requisiti di accessibilità attuali. In questa versione Windows Form ha risolto diversi problemi. Per un elenco completo delle modifiche correlate all'accessibilità, visitare Novità sull'accessibilità in .NET Framework.

Le caratteristiche principali dei miglioramenti apportati a Windows Form in .NET Framework 4.8.1 sono:

  • Supporto pattern di testo: Windows Forms ha aggiunto il supporto per il modello di testo UIA. Questo modello consente alla tecnologia assistiva di percorrere, lettera per lettera, il contenuto di un controllo TextBox o di un controllo simile basato su testo. Consente di selezionare il testo all'interno del controllo e di modificarlo e di inserire nuovo testo nel cursore. Windows Form ha aggiunto questo supporto per TextBox, celle DataGridView, controlli ComboBox e altro ancora.

  • Risolvere i problemi di contrasto: in diversi controlli Windows Form è stato modificato il rapporto di contrasto dei rettangoli di selezione in modo che sia più scuro e più visibile.

  • Sono stati risolti diversi problemi di DataGridView:

    • I nomi della barra di scorrimento sono stati aggiornati in modo che siano coerenti.
    • L'Assistente vocale è ora in grado di focalizzarsi sulle celle DataGridView vuote.
    • Gli sviluppatori possono impostare la proprietà del tipo di controllo localizzato per le celle DataGridView personalizzate.
    • Il colore del collegamento delle celle DataGridViewLink è stato aggiornato per offrire un contrasto migliore con lo sfondo.

Introduzione a .NET Framework 4.8

.NET Framework 4.8 si basa sulle versioni precedenti di .NET Framework 4.x aggiungendo molte nuove correzioni e diverse nuove funzionalità, pur rimanendo un prodotto molto stabile.

Scaricare e installare .NET Framework 4.8

È possibile scaricare .NET Framework 4.8 dai percorsi seguenti:

.NET Framework 4.8 può essere installato in Windows 10, Windows 8.1, Windows 7 SP1 e nelle piattaforme server corrispondenti a partire da Windows Server 2008 R2 SP1. È possibile installare .NET Framework 4.8 usando il programma di installazione Web o il programma di installazione offline. Il modo consigliato per la maggior parte degli utenti consiste nell'usare il programma di installazione Web.

È possibile mirare a .NET Framework 4.8 in Visual Studio 2012 o versioni successive installando il .NET Framework 4.8 Developer Pack.

Novità di .NET Framework 4.8

.NET Framework 4.8 introduce nuove funzionalità nelle aree seguenti:

Miglioramento dell'accessibilità, che consente a un'applicazione di offrire agli utenti di Assistive Technology un'esperienza appropriata, continua a essere un obiettivo importante di .NET Framework 4.8. Per informazioni sui miglioramenti dell'accessibilità in .NET Framework 4.8, vedere Novità dell'accessibilità in .NET Framework.

Classi di base

Riduzione dell'impatto FIPS sulla crittografia. Nelle versioni precedenti di .NET Framework, le classi del provider di crittografia gestito, ad esempio SHA256Managed generano un CryptographicException quando le librerie di crittografia di sistema sono configurate in modalità FIPS. Queste eccezioni vengono generate perché le versioni gestite delle classi del provider di crittografia, a differenza delle librerie di crittografia di sistema, non sono state sottoposte alla certificazione FIPS (Federal Information Processing Standards) 140-2. Poiché pochi sviluppatori hanno i computer di sviluppo in modalità FIPS, le eccezioni vengono comunemente generate nei sistemi di produzione.

Per impostazione predefinita nelle applicazioni destinate a .NET Framework 4.8, le classi di crittografia gestite seguenti non generano più un CryptographicException in questo caso:

Queste classi reindirizzano invece le operazioni di crittografia a una libreria di crittografia di sistema. Questa modifica rimuove in modo efficace una differenza potenzialmente confusa tra gli ambienti di sviluppo e gli ambienti di produzione e rende i componenti nativi e i componenti gestiti operano con gli stessi criteri di crittografia. Le applicazioni che dipendono da queste eccezioni possono ripristinare il comportamento precedente impostando l'opzione AppContext Switch.System.Security.Cryptography.UseLegacyFipsThrow su true. Per ulteriori informazioni, vedere le classi di crittografia, gestite, non generano un'eccezione CryptographyException in modalità FIPS.

Uso della versione aggiornata di ZLib

A partire da .NET Framework 4.5, l'assembly clrcompression.dll usa ZLib, una libreria esterna nativa per la compressione dei dati, per fornire un'implementazione per l'algoritmo deflate. La versione di .NET Framework 4.8 di clrcompression.dll viene aggiornata per usare ZLib versione 1.2.11, che include diversi miglioramenti e correzioni chiave.

Windows Communication Foundation (WCF)

Introduzione al ServiceHealthBehavior

Gli endpoint di salute sono ampiamente usati dagli strumenti di orchestrazione per gestire i servizi in base al loro stato di salute. I controlli di integrità possono essere usati anche dagli strumenti di monitoraggio per tenere traccia e fornire notifiche sulla disponibilità e sulle prestazioni di un servizio.

ServiceHealthBehavior è un comportamento del servizio WCF che estende IServiceBehavior. Quando viene aggiunto alla raccolta di ServiceDescription.Behaviors, un comportamento del servizio esegue le operazioni seguenti:

  • Restituisce lo stato di integrità del servizio con i codici di risposta HTTP. È possibile specificare in una stringa di query il codice di stato HTTP per una richiesta di probe di integrità HTTP/GET.

  • Pubblica informazioni sull'integrità dei servizi. I dettagli specifici del servizio, inclusi lo stato del servizio, i conteggi delle limitazioni e la capacità, possono essere visualizzati usando una richiesta HTTP/GET con la stringa di query ?health. La facilità di accesso a tali informazioni è importante quando si risolve un comportamento errato di un servizio WCF.

Esistono due modi per esporre l'endpoint di stato di salute e pubblicare le informazioni sullo stato di salute del servizio WCF.

  • Tramite il codice. Per esempio:

    ServiceHost host = new ServiceHost(typeof(Service1),
                       new Uri("http://contoso:81/Service1"));
    ServiceHealthBehavior healthBehavior =
        host.Description.Behaviors.Find<ServiceHealthBehavior>();
    healthBehavior ??= new ServiceHealthBehavior();
    host.Description.Behaviors.Add(healthBehavior);
    
  • Usando un file di configurazione. Per esempio:

    <behaviors>
      <serviceBehaviors>
        <behavior name="DefaultBehavior">
          <serviceHealth httpsGetEnabled="true"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
    

È possibile eseguire query sullo stato di integrità di un servizio usando parametri di query come OnServiceFailure, OnDispatcherFailure, OnListenerFailure, OnThrottlePercentExceeded) e è possibile specificare un codice di risposta HTTP per ogni parametro di query. Se il codice di risposta HTTP viene omesso per un parametro di query, per impostazione predefinita viene usato un codice di risposta HTTP 503. Per esempio:

Parametri ed esempi di query:

  • OnDispatcherFailure: https://contoso:81/Service1?health&OnDispatcherFailure=455

    Viene restituito un codice di stato della risposta HTTP 455 quando lo stato di uno qualsiasi dei dispatcher del canale è maggiore di CommunicationState.Opened.

  • OnListenerFailure: https://contoso:81/Service1?health&OnListenerFailure=465

    Viene restituito un codice di stato della risposta HTTP 465 quando lo stato di uno dei listener di canale è maggiore di CommunicationState.Opened.

  • OnThrottlePercentExceeded: https://contoso:81/Service1?health&OnThrottlePercentExceeded= 70:350,95:500

    Specifica la percentuale {1 - 100} che attiva la risposta e il relativo codice di risposta HTTP {200 - 599}. In questo esempio:

    • Se la percentuale è maggiore di 95, viene restituito un codice di risposta HTTP 500.

    • Se la percentuale è compresa tra 70 e 95, viene restituito 350.

    • In caso contrario, viene restituito 200.

Lo stato di integrità del servizio può essere visualizzato in HTML specificando una stringa di query come https://contoso:81/Service1?health o in XML specificando una stringa di query come https://contoso:81/Service1?health&Xml. Una stringa di query come https://contoso:81/Service1?health&NoContent restituisce una pagina HTML vuota.

Windows Presentation Foundation (WPF)

miglioramenti per i DPI elevati

In .NET Framework 4.8 WPF aggiunge il supporto per Per-Monitor riconoscimento DPI V2 e Mixed-Mode ridimensionamento DPI. Consultare Sviluppo di applicazioni desktop ad alto DPI in Windows per altre informazioni sullo sviluppo ad alto DPI.

.NET Framework 4.8 migliora il supporto per gli HWND ospitati e l'interoperabilità di Windows Form nelle applicazioni WPF High-DPI su piattaforme che supportano il ridimensionamento DPI Mixed-Mode (a partire dall'aggiornamento di Windows 10 di aprile 2018). Quando gli HWND o i controlli Windows Forms ospitati vengono creati come finestre con scalabilità DPI Mixed-Mode chiamando SetThreadDpiHostingBehavior e SetThreadDpiAwarenessContext, essi possono essere ospitati in un'applicazione WPF V2 Per-Monitor e vengono ridimensionati e scalati in modo appropriato. Tale contenuto ospitato non viene sottoposto a rendering con valori DPI nativi; Al contrario, il sistema operativo ridimensiona il contenuto ospitato in base alle dimensioni appropriate. Il supporto per Per-Monitor modalità di riconoscimento DPI v2 consente anche di ospitare i controlli WPF (padre) in una finestra nativa in un'applicazione con valori DPI elevati.

Per abilitare il supporto per il ridimensionamento Mixed-Mode DPI elevato, è possibile impostare il AppContext cambia il file di configurazione dell'applicazione:

<runtime>
   <AppContextSwitchOverrides value = "Switch.System.Windows.DoNotScaleForDpiChanges=false; Switch.System.Windows.DoNotUsePresentationDpiCapabilityTier2OrGreater=false"/>
</runtime>

Runtime di linguaggio comune

Il runtime in .NET Framework 4.8 include le modifiche e i miglioramenti seguenti:

Miglioramenti al compilatore JIT. Il compilatore JIT (Just-in-Time) in .NET Framework 4.8 si basa sul compilatore JIT in .NET Core 2.1. Molte delle ottimizzazioni e tutte le correzioni di bug apportate al compilatore JIT di .NET Core 2.1 sono incluse nel compilatore JIT di .NET Framework 4.8.

miglioramenti di NGEN. Il runtime ha migliorato la gestione della memoria per immagini native image generator (NGEN) in modo che i dati mappati dalle immagini NGEN non siano residenti in memoria. In questo modo si riduce la superficie di attacco disponibile per gli attacchi che tentano di eseguire codice arbitrario modificando la memoria che verrà eseguita.

analisi antimalware per tutti gli assembly. Nelle versioni precedenti di .NET Framework, il runtime analizza tutti gli assembly caricati dal disco usando Windows Defender o software antimalware di terze parti. Tuttavia, gli assembly caricati da altre origini, ad esempio dal metodo Assembly.Load(Byte[]), non vengono analizzati e possono potenzialmente contenere malware non rilevato. A partire da .NET Framework 4.8 in esecuzione in Windows 10, il runtime attiva un'analisi da soluzioni antimalware che implementano l'interfaccia AMSI (Antimalware Scan Interface).

Novità di .NET Framework 4.7.2

.NET Framework 4.7.2 include nuove funzionalità nelle aree seguenti:

Nella versione .NET Framework 4.7.2, un'attenzione continua è rivolta al miglioramento dell'accessibilità, che consente a un'applicazione di offrire un'esperienza appropriata per gli utenti di Tecnologie Assistive. Per informazioni sui miglioramenti dell'accessibilità in .NET Framework 4.7.2, vedere Novità dell'accessibilità in .NET Framework.

Classi di base

.NET Framework 4.7.2 offre un numero elevato di miglioramenti crittografici, un migliore supporto per la decompressione per gli archivi ZIP e api di raccolta aggiuntive.

Nuovi overload di RSA.Create e DSA.Create

I metodi DSA.Create(DSAParameters) e RSA.Create(RSAParameters) consentono di specificare i parametri chiave al momento di creare una nuova chiave DSA o RSA. Consentono di sostituire il codice come il seguente:

// Before .NET Framework 4.7.2
using (RSA rsa = RSA.Create())
{
   rsa.ImportParameters(rsaParameters);
   // Other code to execute using the RSA instance.
}

con codice simile al seguente:

// Starting with .NET Framework 4.7.2
using (RSA rsa = RSA.Create(rsaParameters))
{
   // Other code to execute using the rsa instance.
}

I metodi DSA.Create(Int32) e RSA.Create(Int32) consentono di generare nuove chiavi DSA o RSA con dimensioni specifiche della chiave. Per esempio:

using (DSA dsa = DSA.Create(2048))
{
   // Other code to execute using the dsa instance.
}

I costruttori Rfc2898DeriveBytes accettano il nome dell'algoritmo hash

La classe Rfc2898DeriveBytes ha tre nuovi costruttori con un parametro HashAlgorithmName che identifica l'algoritmo HMAC da usare durante la derivazione delle chiavi. Invece di usare SHA-1, gli sviluppatori devono usare un HMAC basato su SHA-2 come SHA-256, come illustrato nell'esempio seguente:

private static byte[] DeriveKey(string password, out int iterations, out byte[] salt,
                                out HashAlgorithmName algorithm)
{
   iterations = 100000;
   algorithm = HashAlgorithmName.SHA256;

   const int SaltSize = 32;
   const int DerivedValueSize = 32;

   using (Rfc2898DeriveBytes pbkdf2 = new Rfc2898DeriveBytes(password, SaltSize,
                                                             iterations, algorithm))
   {
      salt = pbkdf2.Salt;
      return pbkdf2.GetBytes(DerivedValueSize);
   }
}

supporto per le chiavi temporanee

L'importazione PFX può facoltativamente caricare chiavi private direttamente dalla memoria, ignorando il disco rigido. Quando il nuovo flag X509KeyStorageFlags.EphemeralKeySet viene specificato nel costruttore X509Certificate2 o in uno dei sovraccarichi del metodo X509Certificate2.Import, le chiavi private verranno caricate come chiavi temporanee. Ciò impedisce che le chiavi siano visibili sul disco. Tuttavia:

  • Poiché le chiavi non sono salvate su disco, i certificati caricati con questa opzione non sono validi candidati per essere aggiunti a un archivio X509.

  • Le chiavi caricate in questo modo vengono quasi sempre caricate tramite Windows CNG. Pertanto, gli utenti devono accedere alla chiave privata chiamando metodi di estensione, ad esempio cert.GetRSAPrivateKey(). La proprietà X509Certificate2.PrivateKey non funziona.

  • Poiché la proprietà legacy X509Certificate2.PrivateKey non funziona con i certificati, gli sviluppatori devono eseguire test rigorosi prima di passare alle chiavi temporanee.

creazione programmatica di richieste di firma di certificazione PKCS#10 e certificati di chiave pubblica X.509

A partire da .NET Framework 4.7.2, i carichi di lavoro possono generare richieste di firma dei certificati (CSR), che consentono di eseguire il staging della generazione delle richieste di certificato in strumenti esistenti. Questa operazione è spesso utile negli scenari di test.

Per altre informazioni ed esempi di codice, vedere "Creazione a livello di codice delle richieste di firma di certificazione PKCS#10 e certificati di chiave pubblica X.509" nel blog .NET.

nuovi membri SignerInfo

A partire da .NET Framework 4.7.2, la classe SignerInfo espone altre informazioni sulla firma. È possibile recuperare il valore della proprietà System.Security.Cryptography.Pkcs.SignerInfo.SignatureAlgorithm per determinare l'algoritmo di firma utilizzato dal firmatario. È possibile chiamare SignerInfo.GetSignature per ottenere una copia della firma crittografica di questo firmatario.

Lasciare aperto un flusso incapsulato dopo la chiusura di CryptoStream

A partire da .NET Framework 4.7.2, la classe CryptoStream dispone di un costruttore aggiuntivo che permette a Dispose di lasciare aperto il flusso incapsulato. Per lasciare aperto il flusso avvolto dopo la distruzione dell'istanza di CryptoStream, chiamare il nuovo costruttore CryptoStream come segue:

var cStream = new CryptoStream(stream, transform, mode, leaveOpen: true);

modifiche alla decompressione in DeflateStream

A partire da .NET Framework 4.7.2, l'implementazione di operazioni di decompressione nella classe DeflateStream è stata modificata per usare le API Windows native per impostazione predefinita. In genere, ciò comporta un miglioramento sostanziale delle prestazioni.

Il supporto per la decompressione tramite le API Di Windows è abilitato per impostazione predefinita per le applicazioni destinate a .NET Framework 4.7.2. Le applicazioni destinate a versioni precedenti di .NET Framework ma in esecuzione in .NET Framework 4.7.2 possono acconsentire esplicitamente a questo comportamento aggiungendo il seguente commutatore AppContext al file di configurazione dell'applicazione.

<AppContextSwitchOverrides value="Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression=false" />

API di raccolta aggiuntive

.NET Framework 4.7.2 aggiunge una serie di nuove API ai tipi SortedSet<T> e HashSet<T>. Questi includono:

La classe ConcurrentDictionary<TKey,TValue> include nuovi overload dei metodi AddOrUpdate e GetOrAdd per recuperare un valore dal dizionario o aggiungerlo se non viene trovato e aggiungere un valore al dizionario o aggiornarlo se esiste già.

public TValue AddOrUpdate<TArg>(TKey key, Func<TKey, TArg, TValue> addValueFactory, Func<TKey, TValue, TArg, TValue> updateValueFactory, TArg factoryArgument)

public TValue GetOrAdd<TArg>(TKey key, Func<TKey, TArg, TValue> valueFactory, TArg factoryArgument)

ASP.NET

Supporto per l'iniezione delle dipendenze nei Web Forms

L'iniezione delle dipendenze (DI) disaccoppiando gli oggetti e le relative dipendenze in modo che il codice di un oggetto non debba più essere modificato solo perché è stata modificata una dipendenza. Quando si sviluppano applicazioni ASP.NET destinate a .NET Framework 4.7.2, è possibile:

  • Usare l'iniezione basata su setter, su interfaccia e su costruttore nei gestori e nei moduli, nelle istanze di paginae e nei controlli utente e di progetti di applicazioni Web ASP.NET.

  • Usare l'inserimento basato su setter e interfacce nei gestori e nei moduli, istanze di pagina e controlli utente nei progetti web ASP.NET.

  • Integrare diversi framework per l'iniezione delle dipendenze.

supporto per i cookie dello stesso sito

SameSite impedisce a un browser di inviare un cookie insieme a una richiesta tra siti. .NET Framework 4.7.2 aggiunge una proprietà HttpCookie.SameSite il cui valore è un membro di enumerazione System.Web.SameSiteMode. Se il valore è SameSiteMode.Strict o SameSiteMode.Lax, ASP.NET aggiunge l'attributo SameSite all'intestazione set-cookie. Il supporto sameSite si applica agli oggetti HttpCookie, nonché ai cookie di FormsAuthentication e System.Web.SessionState.

È possibile impostare SameSite per un oggetto HttpCookie come indicato di seguito:

var c = new HttpCookie("secureCookie", "same origin");
c.SameSite = SameSiteMode.Lax;

È anche possibile configurare i cookie SameSite a livello di applicazione modificando il file web.config:

<system.web>
   <httpCookies sameSite="Strict" />
</system.web>

È possibile aggiungere SameSite per FormsAuthentication e System.Web.SessionState cookie modificando il file di configurazione Web:

<system.web>
   <authentication mode="Forms">
      <forms cookieSameSite="Lax">
         <!-- ...   -->
      </forms>
   </authentication>
   <sessionState cookieSameSite="Lax"></sessionState>
</system.web>

Rete informatica

Implementazione delle proprietà HttpClientHandler

.NET Framework 4.7.1 ha aggiunto otto proprietà alla classe System.Net.Http.HttpClientHandler. Tuttavia, due hanno lanciato un PlatformNotSupportedException. .NET Framework 4.7.2 offre ora un'implementazione per queste proprietà. Le proprietà sono:

SQLClient

supporto per l'autenticazione universale di Azure Active Directory e l'autenticazione a più fattori

Le crescenti esigenze di conformità e sicurezza richiedono che molti clienti usino l'autenticazione a più fattori (MFA). Inoltre, le procedure consigliate correnti sconsigliano l'inclusione delle password utente direttamente nelle stringhe di connessione. Per supportare queste modifiche, .NET Framework 4.7.2 estende stringhe di connessione SQLClient aggiungendo un nuovo valore, "Active Directory Interactive", per la parola chiave "Authentication" esistente per supportare MFA e l'autenticazione di Azure AD. Il nuovo metodo interattivo supporta gli utenti nativi e federati di Azure AD e gli utenti guest di Azure AD. Quando si usa questo metodo, l'autenticazione MFA imposta da Azure AD è supportata per i database SQL. Inoltre, il processo di autenticazione richiede a una password utente di rispettare le procedure consigliate per la sicurezza.

Nelle versioni precedenti di .NET Framework, la connettività SQL supporta solo le opzioni di SqlAuthenticationMethod.ActiveDirectoryPassword e SqlAuthenticationMethod.ActiveDirectoryIntegrated. Entrambi fanno parte del protocollo ADAL non interattivo, che non supporta MFA. Con la nuova opzione SqlAuthenticationMethod.ActiveDirectoryInteractive, la connettività SQL supporta l'autenticazione a più fattori e i metodi di autenticazione esistenti (password e autenticazione integrata), che consente agli utenti di immettere le password utente in modo interattivo senza rendere persistenti le password nella stringa di connessione.

Per altre informazioni e un esempio, vedere "SQL - Supporto dell'autenticazione universale e a più fattori di Azure AD" nel blog .NET.

Supporto per Always Encrypted versione 2

NET Framework 4.7.2 aggiunge il supporto per Always Encrypted basato su enclave. La versione originale di Always Encrypted è una tecnologia di crittografia lato client in cui le chiavi di crittografia non lasciano mai il client. In Always Encrypted basato su enclave, il client può facoltativamente inviare le chiavi di crittografia a un enclave sicura, che è un'entità di calcolo sicura ritenuta parte integrante di SQL Server, ma con cui il codice di SQL Server non può interferire. Per supportare Always Encrypted basato su enclave, .NET Framework 4.7.2 aggiunge i tipi e i membri seguenti allo spazio dei nomi System.Data.SqlClient:

Il file di configurazione dell'applicazione specifica quindi un'implementazione concreta della classe astratta System.Data.SqlClient.SqlColumnEncryptionEnclaveProvider che fornisce la funzionalità per il provider di enclave. Per esempio:

<configuration>
  <configSections>
    <section name="SqlColumnEncryptionEnclaveProviders" type="System.Data.SqlClient.SqlColumnEncryptionEnclaveProviderConfigurationSection,System.Data,Version=4.0.0.0,Culture=neutral,PublicKeyToken=b77a5c561934e089"/>
  </configSections>
  <SqlColumnEncryptionEnclaveProviders>
    <providers>
      <add name="Azure" type="Microsoft.SqlServer.Management.AlwaysEncrypted.AzureEnclaveProvider,MyApp"/>
      <add name="HGS" type="Microsoft.SqlServer.Management.AlwaysEncrypted.HGSEnclaveProvider,MyApp" />
    </providers>
  </SqlColumnEncryptionEnclaveProviders >
</configuration>

Il flusso di base di Always Encrypted con enclave è il seguente:

  1. L'utente crea una connessione AlwaysEncrypted a SQL Server che supporta Always Encrypted basata sull'enclave. Il driver contatta il servizio di attestazione per assicurarsi che si stia connettendo all'enclave corretta.

  2. Dopo l'attestazione dell'enclave, il driver stabilisce un canale sicuro con l'enclave sicura ospitata in SQL Server.

  3. Il driver condivide le chiavi di crittografia autorizzate dal client con l'enclave sicuro per la durata della connessione SQL.

Windows Presentation Foundation

ricerca di ResourceDictionaries per origine

A partire da .NET Framework 4.7.2, un assistente di diagnostica può individuare i ResourceDictionaries creati da un URI di origine specificato. Questa funzionalità viene usata dagli assistenti di diagnostica, non dalle applicazioni di produzione. Un assistente di diagnostica, come ad esempio la funzione "Modifica e Continua" di Visual Studio, consente all'utente di modificare un ResourceDictionary con l'intento di applicare le modifiche all'applicazione in esecuzione. Un passaggio per raggiungere questo obiettivo consiste nel trovare tutti i ResourceDictionaries creati dall'applicazione in esecuzione dal dizionario da modificare. Ad esempio, un'applicazione può dichiarare un ResourceDictionary il cui contenuto viene copiato da un URI di origine specificato:

<ResourceDictionary Source="MyRD.xaml" />

L'assistente diagnostico, che modifica il markup originale in MyRD.xaml, può utilizzare la nuova funzionalità per individuare il dizionario. La funzionalità viene implementata da un nuovo metodo statico, ResourceDictionaryDiagnostics.GetResourceDictionariesForSource. L'assistente diagnostica chiama il nuovo metodo usando un Uri assoluto che identifica il markup originale, come illustrato nel codice seguente:

IEnumerable<ResourceDictionary> dictionaries = ResourceDictionaryDiagnostics.GetResourceDictionariesForSource(new Uri("pack://application:,,,/MyApp;component/MyRD.xaml"));

Il metodo restituisce un'enumerabile vuota a meno che non sia abilitata VisualDiagnostics e la variabile di ambiente ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO sia impostata.

Ricerca di proprietari ResourceDictionary

A partire da .NET Framework 4.7.2, un assistente di diagnostica può individuare i proprietari di un determinato ResourceDictionary. La funzionalità è destinata all'uso da parte di assistenti di diagnostica e non da applicazioni di produzione. Ogni volta che viene apportata una modifica a un ResourceDictionary, WPF trova automaticamente tutti i riferimenti DynamicResource che potrebbero essere interessati dalla modifica.

Un assistente di diagnostica, come la funzionalità "Modifica e Continuazione" di Visual Studio, potrebbe voler estendere questa capacità per gestire i riferimenti StaticResource. Il primo passaggio di questo processo consiste nel trovare i proprietari del dizionario; ovvero per trovare tutti gli oggetti la cui proprietà Resources fa riferimento al dizionario (direttamente o indirettamente tramite la proprietà ResourceDictionary.MergedDictionaries). Tre nuovi metodi statici implementati nella classe System.Windows.Diagnostics.ResourceDictionaryDiagnostics, uno per ciascuno dei tipi di base con una proprietà Resources, supportano questo passaggio.

Questi metodi restituiscono un'enumerabile vuota a meno che non sia abilitata VisualDiagnostics e la variabile di ambiente ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO sia impostata.

Ricerca dei riferimenti StaticResource

Un assistente di diagnostica può ora ricevere una notifica ogni volta che viene risolto un riferimento StaticResource. La funzionalità è destinata all'uso da parte di assistenti di diagnostica, non dalle applicazioni di produzione. Un assistente di diagnostica, ad esempio la funzionalità "Modifica e continuazione" di Visual Studio può voler aggiornare tutti gli usi di una risorsa quando il relativo valore in un ResourceDictionary cambia. WPF fa questo automaticamente per i riferimenti DynamicResource, ma intenzionalmente non lo fa per i riferimenti StaticResource. A partire da .NET Framework 4.7.2, l'assistente diagnostica può usare queste notifiche per individuare gli usi della risorsa statica.

La notifica viene implementata dal nuovo evento ResourceDictionaryDiagnostics.StaticResourceResolved:

public static event EventHandler<StaticResourceResolvedEventArgs> StaticResourceResolved;

Questo evento viene generato ogni volta che il runtime risolve un riferimento StaticResource. Gli argomenti StaticResourceResolvedEventArgs descrivono la risoluzione e indicano l'oggetto e la proprietà che ospitano il riferimento StaticResource e il ResourceDictionary e la chiave usati per la risoluzione:

public class StaticResourceResolvedEventArgs : EventArgs
{
   public Object TargetObject { get; }

   public Object TargetProperty { get; }

   public ResourceDictionary ResourceDictionary { get; }

   public object ResourceKey { get; }
}

L'evento non viene generato (e la relativa funzione di accesso add viene ignorata), a meno che VisualDiagnostics non sia abilitato e la variabile di ambiente ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO non sia impostata.

ClickOnce

Le applicazioni in grado di supportare HDPI per Windows Form, Windows Presentation Foundation (WPF) e Visual Studio Tools per Office (VSTO) possono essere distribuite usando ClickOnce. Se la voce seguente viene trovata nel manifesto dell'applicazione, la distribuzione avrà esito positivo in .NET Framework 4.7.2:

<windowsSettings>
   <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
</windowsSettings>

Per l'applicazione Windows Form, la soluzione alternativa precedente all'impostazione del riconoscimento DPI nel file di configurazione dell'applicazione anziché nel manifesto dell'applicazione non è più necessaria affinché la distribuzione ClickOnce abbia esito positivo.

Novità di .NET Framework 4.7.1

.NET Framework 4.7.1 include nuove funzionalità nelle aree seguenti:

Inoltre, un importante obiettivo di .NET Framework 4.7.1 è il miglioramento dell'accessibilità, che consente a un'applicazione di offrire un'esperienza appropriata per gli utenti di tecnologie assistive. Per informazioni sui miglioramenti dell'accessibilità in .NET Framework 4.7.1, vedere Novità dell'accessibilità in .NET Framework.

Classi di base

supporto per .NET Standard 2.0

.NET Standard definisce un set di API che devono essere disponibili in ogni implementazione di .NET che supporta tale versione dello standard. .NET Framework 4.7.1 supporta completamente .NET Standard 2.0 e aggiunge circa 200 API definite in .NET Standard 2.0 e mancanti in .NET Framework 4.6.1, 4.6.2 e 4.7. Si noti che queste versioni di .NET Framework supportano .NET Standard 2.0 solo se nel sistema di destinazione vengono distribuiti anche file di supporto .NET Standard aggiuntivi. Per altre informazioni, vedere "BCL - Supporto di .NET Standard 2.0" nel post di blog runtime e funzionalità del compilatore di .NET Framework 4.7.1.

supporto per i generatori di configurazione

I generatori di configurazioni consentono agli sviluppatori di inserire e compilare le impostazioni di configurazione per le applicazioni in modo dinamico in fase di esecuzione. I generatori di configurazioni personalizzati possono essere usati per modificare i dati esistenti in una sezione di configurazione o per creare una sezione di configurazione interamente da zero. Senza generatori di configurazioni, .config file sono statici e le relative impostazioni vengono definite qualche tempo prima dell'avvio di un'applicazione.

Per creare un generatore di configurazioni personalizzato, devi derivare il tuo generatore dalla classe ConfigurationBuilder astratta e sovrascrivere il relativo ConfigurationBuilder.ProcessConfigurationSection e ConfigurationBuilder.ProcessRawXml. È anche possibile definire i generatori nel file .config. Per altre informazioni, vedere la sezione "Generatori di configurazione" nel post di blog .NET Framework 4.7.1 ASP.NET e Funzionalità di configurazione.

rilevamento delle funzionalità di runtime

La classe System.Runtime.CompilerServices.RuntimeFeature fornisce un meccanismo per determinare se una funzionalità predefinita è supportata in una determinata implementazione .NET in fase di compilazione o in fase di esecuzione. In fase di compilazione, un compilatore può verificare se esiste un campo specificato per determinare se la funzionalità è supportata; in tal caso, può generare codice che sfrutta tale funzionalità. In fase di esecuzione, un'applicazione può chiamare il metodo RuntimeFeature.IsSupported prima di emettere codice in fase di esecuzione. Per altre informazioni, vedere Aggiungere un metodo helper per descrivere le funzionalità supportate dal runtime.

Tipi di tupla Value sono serializzabili

A partire da .NET Framework 4.7.1, System.ValueTuple e i tipi generici associati vengono contrassegnati come Serializable, che consente la serializzazione binaria. Ciò dovrebbe semplificare la migrazione dei tipi di tupla, ad esempio Tuple<T1,T2,T3> e Tuple<T1,T2,T3,T4>, ai tipi di tupla di valori. Per ulteriori informazioni, vedere "Compiler -- ValueTuple is Serializable" nel post di blog Funzionalità del runtime e del compilatore di .NET Framework 4.7.1.

Supporto per i riferimenti di sola lettura

.NET Framework 4.7.1 introduce il System.Runtime.CompilerServices.IsReadOnlyAttribute. Questo attributo viene usato dai compilatori del linguaggio per contrassegnare i membri che hanno tipi di ritorno ref o parametri di sola lettura. Per altre informazioni, vedere "Compilatore - Supporto per ReadOnlyReferences" nel post di blog funzionalità del runtime e del compilatore di .NET Framework 4.7.1. Per informazioni sui valori restituiti ref, vedere Valori restituiti ref e variabili locali ref e Valori restituiti ref (Visual Basic).

Common Language Runtime (CLR)

miglioramenti delle prestazioni di Garbage Collection

Le modifiche apportate al Garbage Collection (GC) in .NET Framework 4.7.1 migliorano le prestazioni complessive, soprattutto per le allocazioni del Large Object Heap (LOH). In .NET Framework 4.7.1, vengono utilizzati blocchi separati per le allocazioni SOH (Small Object Heap) e LOH, che consente alle allocazioni LOH di verificarsi quando il background GC esegue lo sweep del SOH. Di conseguenza, le applicazioni che effettuano un numero elevato di allocazioni LOH dovrebbero vedere una riduzione della contesa sui blocchi di allocazione e ottenere performance migliori. Per ulteriori informazioni, consultare la sezione "Runtime -- GC Performance Improvements" nel post del blog sulla Runtime e sulle funzionalità del compilatore di .NET Framework 4.7.1 .

Rete di contatti

supporto SHA-2 per message.HashAlgorithm

In .NET Framework 4.7 e versioni precedenti la proprietà Message.HashAlgorithm supporta solo i valori di HashAlgorithm.Md5 e HashAlgorithm.Sha. A partire da .NET Framework 4.7.1, sono supportati anche HashAlgorithm.Sha256, HashAlgorithm.Sha384e HashAlgorithm.Sha512. Se questo valore viene effettivamente usato dipende da MSMQ, poiché l'istanza di Message stessa non esegue hashing, ma passa semplicemente i valori a MSMQ. Per altre informazioni, vedere la sezione "Supporto SHA-2 per Message.HashAlgorithm" nel post di blog .NET Framework 4.7.1 ASP.NET e Configurazione.

ASP.NET

Passaggi di esecuzione nelle applicazioni ASP.NET

ASP.NET elabora le richieste in una pipeline predefinita che include 23 eventi. ASP.NET esegue ciascun gestore eventi come un passaggio di esecuzione. Nelle versioni di ASP.NET fino a .NET Framework 4.7, ASP.NET non può scorrere il contesto di esecuzione a causa del passaggio tra thread nativi e gestiti. Invece, ASP.NET propaga in modo selettivo solo il HttpContext. A partire da .NET Framework 4.7.1, il metodo HttpApplication.OnExecuteRequestStep(Action<HttpContextBase,Action>) consente anche ai moduli di ripristinare i dati di ambiente. Questa funzionalità è destinata alle librerie che si occupano di monitoraggio, profilazione, diagnostica o transazioni, ad esempio, per il controllo del flusso di esecuzione dell'applicazione. Per altre informazioni, vedere la funzionalità "ASP.NET execution step" nel post di blog .NET Framework 4.7.1 ASP.NET e funzionalità di configurazione.

Analisi di ASP.NET HttpCookie

.NET Framework 4.7.1 include un nuovo metodo, HttpCookie.TryParse, che fornisce un modo standardizzato per creare un oggetto HttpCookie da una stringa e assegnare con precisione i valori dei cookie, ad esempio la data di scadenza e il percorso. Per altre informazioni, vedere "analisi ASP.NET HttpCookie" nel post di blog .NET Framework 4.7.1 ASP.NET e Funzionalità di configurazione.

opzioni hash SHA-2 per le credenziali di autenticazione di moduli ASP.NET

In .NET Framework 4.7 e versioni precedenti, ASP.NET consentiva agli sviluppatori di archiviare le credenziali utente con password in forma di hash nei file di configurazione usando MD5 o SHA1. A partire da .NET Framework 4.7.1, ASP.NET supporta anche nuove opzioni hash SHA-2 sicure, ad esempio SHA256, SHA384 e SHA512. SHA1 rimane l'impostazione predefinita e un algoritmo hash non predefinito può essere definito nel file di configurazione Web.

Importante

Microsoft consiglia di usare il flusso di autenticazione più sicuro disponibile. Se ti connetti ad Azure SQL, le Identità Gestite per le risorse di Azure sono il metodo di autenticazione consigliato.

Novità di .NET Framework 4.7

.NET Framework 4.7 include nuove funzionalità nelle aree seguenti:

Per un elenco delle nuove API aggiunte a .NET Framework 4.7, vedere modifiche all'API di .NET Framework 4.7 in GitHub. Per un elenco dei miglioramenti delle funzionalità e delle correzioni di bug in .NET Framework 4.7, vedere elenco delle modifiche di .NET Framework 4.7 in GitHub. Per ulteriori informazioni, vedere Annunciando .NET Framework 4.7 nel blog di .NET.

Classi di base

.NET Framework 4.7 migliora la serializzazione tramite il DataContractJsonSerializer:

Funzionalità avanzata con* Elliptic Curve Cryptography (ECC)

In .NET Framework 4.7 sono stati aggiunti ImportParameters(ECParameters) metodi alle classi ECDsa e ECDiffieHellman per consentire a un oggetto di rappresentare una chiave già stabilita. È stato aggiunto anche un metodo ExportParameters(Boolean) per l'esportazione della chiave usando parametri di curva espliciti.

.NET Framework 4.7 aggiunge anche il supporto per curve aggiuntive (incluso il gruppo di curve Brainpool) e ha aggiunto definizioni predefinite per facilitare la creazione tramite i nuovi metodi di Create e Create factory.

È possibile visualizzare un esempio di miglioramenti della crittografia di .NET Framework 4.7 su GitHub.

Supporto migliore per i caratteri di controllo da parte di DataContractJsonSerializer

In .NET Framework 4.7 la classe DataContractJsonSerializer serializza i caratteri di controllo in conformità allo standard ECMAScript 6. Questo comportamento è abilitato per impostazione predefinita per le applicazioni destinate a .NET Framework 4.7 ed è una funzionalità di consenso esplicito per le applicazioni in esecuzione in .NET Framework 4.7, ma destinate a una versione precedente di .NET Framework. Per ulteriori informazioni, vedere la sezione compatibilità delle applicazioni.

Creazione di reti di contatti

.NET Framework 4.7 aggiunge la funzionalità correlata alla rete seguente:

Supporto predefinito del sistema operativo per i protocolli TLS*

Lo stack TLS, usato da System.Net.Security.SslStream e dai componenti dello stack up-stack, ad esempio HTTP, FTP e SMTP, consente agli sviluppatori di usare i protocolli TLS predefiniti supportati dal sistema operativo. Gli sviluppatori non devono più scrivere una specifica versione TLS nel codice.

ASP.NET

In .NET Framework 4.7 ASP.NET include le nuove funzionalità seguenti:

Estendibilità della cache degli oggetti

A partire da .NET Framework 4.7, ASP.NET aggiunge un nuovo set di API che consentono agli sviluppatori di sostituire le implementazioni di ASP.NET predefinite per la memorizzazione nella cache degli oggetti in memoria e il monitoraggio della memoria. Gli sviluppatori possono ora sostituire uno dei tre componenti seguenti se l'implementazione ASP.NET non è adeguata:

  • L'archivio cache oggetti. Usando la sezione di configurazione dei nuovi provider di cache, gli sviluppatori possono collegare nuove implementazioni di una cache di oggetti per un'applicazione ASP.NET usando la nuova interfaccia ICacheStoreProvider.

  • monitoraggio della memoria. Il monitor della memoria predefinito in ASP.NET notifica alle applicazioni quando sono vicine al limite configurato di byte privati per il processo o quando il computer ha poca RAM fisica totale disponibile. Quando questi limiti si avvicinano, vengono attivate le notifiche. Per alcune applicazioni, le notifiche vengono attivate troppo vicino ai limiti configurati per consentire reazioni utili. Gli sviluppatori possono ora scrivere monitoraggi di memoria personalizzati per sostituire l'impostazione predefinita usando la proprietà ApplicationMonitors.MemoryMonitor.

  • Reazioni al limite di memoria. Per impostazione predefinita, ASP.NET tenta di ridurre la cache degli oggetti e chiamare periodicamente GC.Collect quando il limite di byte privati del processo è vicino. Per alcune applicazioni, la frequenza delle chiamate a GC.Collect o la quantità di cache tagliata sono inefficienti. Gli sviluppatori possono ora sostituire o integrare il comportamento predefinito sottoscrivendo implementazioni di IObserver al monitoraggio della memoria dell'applicazione.

Windows Communication Foundation (WCF)

Windows Communication Foundation (WCF) aggiunge le funzionalità e le modifiche seguenti:

Possibilità di configurare le impostazioni di sicurezza dei messaggi predefinite per TLS 1.1 o TLS 1.2

A partire da .NET Framework 4.7, WCF consente di configurare TLS 1.1 o TLS 1.2 oltre a SSL 3.0 e TLS 1.0 come protocollo di sicurezza dei messaggi predefinito. Si tratta di un'impostazione di consenso esplicito; per abilitarlo, è necessario aggiungere la voce seguente al file di configurazione dell'applicazione:

<runtime>
   <AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols=false;Switch.System.Net.DontEnableSchUseStrongCrypto=false" />
</runtime>

Maggiore affidabilità delle applicazioni WCF e della serializzazione WCF

WCF include una serie di modifiche al codice che eliminano le race condition, migliorando così le prestazioni e l'affidabilità delle opzioni di serializzazione. Questi includono:

  • Supporto migliore per la combinazione di codice asincrono e sincrono nelle chiamate a SocketConnection.BeginRead e SocketConnection.Read.
  • Maggiore affidabilità quando si interrompe una connessione con SharedConnectionListener e con DuplexChannelBinder.
  • Maggiore affidabilità delle operazioni di serializzazione quando si chiama il metodo FormatterServices.GetSerializableMembers(Type).
  • Miglioramento dell'affidabilità quando si rimuove un cameriere chiamando il metodo ChannelSynchronizer.RemoveWaiter.

Windows Forms

In .NET Framework 4.7 Windows Form migliora il supporto per i monitoraggi DPI elevati.

supporto dpi elevato

A partire dalle applicazioni destinate a .NET Framework 4.7, .NET Framework offre un supporto DPI alto e DPI dinamico per le applicazioni Windows Forms. Il supporto per l'alta DPI migliora il layout e l'aspetto dei moduli e dei controlli su monitor ad alta risoluzione. Il valore DPI dinamico modifica il layout e l'aspetto dei moduli e dei controlli quando l'utente modifica il fattore di scala DPI o display di un'applicazione in esecuzione.

Il supporto di valori DPI elevati è una funzionalità di consenso esplicito configurata definendo una sezione <System.Windows.Forms.ConfigurationSection> nel file di configurazione dell'applicazione. Per ulteriori informazioni sull'aggiunta del supporto DPI elevato e del supporto DPI dinamico all'applicazione Windows Forms, vedere Supporto DPI elevato in Windows Forms.

Windows Presentation Foundation (WPF)

In .NET Framework 4.7 WPF include i miglioramenti seguenti:

supporto per uno stack di stilo/tocco basato sui messaggi di Windows WM_POINTER

È ora possibile usare uno stack di tocco/stilo basato sui messaggi WM_POINTER anziché su Windows Ink Services Platform (WISP). Si tratta di una funzionalità di consenso esplicito in .NET Framework. Per ulteriori informazioni, vedere la sezione compatibilità delle applicazioni.

Nuova implementazione per le API di stampa WPF

Le API di stampa di WPF nella classe System.Printing.PrintQueue chiamano l'API Stampa pacchetto documento di Windows invece dell'API di stampa XPS deprecata. Per l'impatto di questa modifica sulla compatibilità delle applicazioni, vedere la sezione relativa alla compatibilità delle applicazioni .

Novità di .NET Framework 4.6.2

.NET Framework 4.6.2 include nuove funzionalità nelle aree seguenti:

Per un elenco delle nuove API aggiunte a .NET Framework 4.6.2, vedere modifiche all'API di .NET Framework 4.6.2 in GitHub. Per un elenco dei miglioramenti delle funzionalità e delle correzioni di bug in .NET Framework 4.6.2, vedere elenco delle modifiche di .NET Framework 4.6.2 in GitHub. Per altre informazioni, vedere Annuncio del .NET Framework 4.6.2 nel blog di .NET.

ASP.NET

In .NET Framework 4.6.2 ASP.NET include i miglioramenti seguenti:

Supporto migliorato per i messaggi di errore localizzati nei validator di annotazione dati

I validator di annotazione dati consentono di eseguire la convalida aggiungendo uno o più attributi a una proprietà di classe. L'elemento ValidationAttribute.ErrorMessage dell'attributo definisce il testo del messaggio di errore in caso di esito negativo della convalida. A partire da .NET Framework 4.6.2, ASP.NET semplifica la localizzazione dei messaggi di errore. I messaggi di errore verranno localizzati se:

  1. Il ValidationAttribute.ErrorMessage viene fornito nell'attributo di convalida.

  2. Il file di risorse viene archiviato nella cartella App_LocalResources.

  3. Il nome del file di risorse localizzato ha il formato DataAnnotation.Localization.{nome}.resx, dove nome è un nome cultura nel formato codiceLingua-codicePaese/areaGeografica o codiceLingua.

  4. Il nome della chiave della risorsa è la stringa assegnata all'attributo ValidationAttribute.ErrorMessage e il relativo valore è il messaggio di errore localizzato.

Ad esempio, il seguente attributo di annotazione dati definisce il messaggio di errore della cultura predefinita per una valutazione non valida.

public class RatingInfo
{
   [Required(ErrorMessage = "The rating must be between 1 and 10.")]
   [Display(Name = "Your Rating")]
   public int Rating { get; set; }
}

È quindi possibile creare un file di risorse, DataAnnotation.Localization.fr.resx, la cui chiave è la stringa del messaggio di errore e il cui valore è il messaggio di errore localizzato. Il file deve essere trovato nella cartella App.LocalResources. Ad esempio, di seguito è riportata la chiave e il relativo valore in un messaggio di errore in francese localizzato (fr):

Nome Valore
La classificazione deve essere compresa tra 1 e 10. La note deve essere compresa tra 1 e 10.

Inoltre, la localizzazione delle annotazioni dei dati è estendibile. Gli sviluppatori possono collegare il proprio provider di localizzatori di stringhe implementando l'interfaccia IStringLocalizerProvider per archiviare la stringa di localizzazione in un punto diverso da un file di risorse.

Il supporto asincrono con i provider dello stato della sessione

ASP.NET ora consente l'uso di metodi di restituzione delle attività con provider di archiviazione con stato sessione, consentendo così alle app di ASP.NET di ottenere i vantaggi di scalabilità di asincrona. Per supportare le operazioni asincrone con i provider di archiviazione dello stato di sessione, ASP.NET include una nuova interfaccia, System.Web.SessionState.ISessionStateModule, che eredita da IHttpModule e consente agli sviluppatori di implementare il proprio modulo di stato della sessione e provider di archiviazione dello stato di sessione asincroni. L'interfaccia è definita come segue:

public interface ISessionStateModule : IHttpModule {
    void ReleaseSessionState(HttpContext context);
    Task ReleaseSessionStateAsync(HttpContext context);
}

Inoltre, la classe SessionStateUtility include due nuovi metodi, IsSessionStateReadOnly e IsSessionStateRequired, che possono essere usati per supportare operazioni asincrone.

Supporto asincrono per i provider del cache di output

A partire da .NET Framework 4.6.2, i metodi di restituzione delle attività possono essere usati con i provider di cache di output per offrire i vantaggi di scalabilità di async. I provider che implementano questi metodi riducono il blocco dei thread in un server Web e migliorano la scalabilità di un servizio ASP.NET.

Sono state aggiunte le API seguenti per supportare provider di cache di output asincroni:

Categorie di caratteri

I caratteri in .NET Framework 4.6.2 vengono classificati in base allo standard Unicode versione 8.0.0. In .NET Framework 4.6 e .NET Framework 4.6.1 i caratteri sono stati classificati in base alle categorie di caratteri Unicode 6.3.

Il supporto per Unicode 8.0 è limitato alla classificazione dei caratteri dalla classe CharUnicodeInfo e ai tipi e ai metodi che si basano su di esso. Sono incluse la classe StringInfo, il metodo Char.GetUnicodeCategory sovraccarico e le classi di caratteri e riconosciute dal motore delle espressioni regolari di .NET Framework. Il confronto tra caratteri e stringhe e l'ordinamento non sono interessati da questa modifica e continuano a basarsi sul sistema operativo sottostante o, nei sistemi Windows 7, sui dati di carattere forniti da .NET Framework.

Per le modifiche apportate alle categorie di caratteri da Unicode 6.0 a Unicode 7.0, vedere The Unicode Standard, Version 7.0.0 nel sito Web Di Unicode Consortium. Per le modifiche da Unicode 7.0 a Unicode 8.0, vedere The Unicode Standard, Version 8.0.0 sul sito web del Unicode Consortium.

Crittografia

supporto per certificati X509 contenenti DSA FIPS 186-3

.NET Framework 4.6.2 aggiunge il supporto per i certificati X509 DSA (Digital Signature Algorithm) le cui chiavi superano il limite FIPS 186-2 a 1024 bit.

Oltre a supportare le dimensioni maggiori delle chiavi di FIPS 186-3, .NET Framework 4.6.2 consente di calcolare le firme con la famiglia sha-2 di algoritmi hash (SHA256, SHA384 e SHA512). Il supporto FIPS 186-3 viene fornito dalla nuova classe System.Security.Cryptography.DSACng.

In conformità alle recenti modifiche apportate alla classe RSA in .NET Framework 4.6 e alla classe ECDsa in .NET Framework 4.6.1, la classe base astratta DSA in .NET Framework 4.6.2 include metodi aggiuntivi per consentire ai chiamanti di usare questa funzionalità senza eseguire il cast. È possibile chiamare il metodo di estensione DSACertificateExtensions.GetDSAPrivateKey per firmare i dati, come illustrato nell'esempio seguente.

public static byte[] SignDataDsaSha384(byte[] data, X509Certificate2 cert)
{
    using (DSA dsa = cert.GetDSAPrivateKey())
    {
        return dsa.SignData(data, HashAlgorithmName.SHA384);
    }
}

È anche possibile chiamare il metodo di estensione DSACertificateExtensions.GetDSAPublicKey per verificare i dati firmati, come illustrato nell'esempio seguente.

public static bool VerifyDataDsaSha384(byte[] data, byte[] signature, X509Certificate2 cert)
{
    using (DSA dsa = cert.GetDSAPublicKey())
    {
        return dsa.VerifyData(data, signature, HashAlgorithmName.SHA384);
    }
}

Maggiore chiarezza per gli input nelle routine di derivazione della chiave ECDiffieHellman

.NET Framework 3.5 ha aggiunto il supporto per l'accordo chiave curva ellittica Diffie-Hellman con tre diverse routine di funzioni di derivazione delle chiavi. Gli input delle routine e le routine stesse sono stati configurati tramite proprietà sull'oggetto ECDiffieHellmanCng. Ma poiché non tutte le routine leggono ogni proprietà di input, c'era ampio spazio per confusione sul passato dello sviluppatore.

Per risolvere questo problema in .NET Framework 4.6.2, sono stati aggiunti i tre metodi seguenti alla classe base ECDiffieHellman per rappresentare in modo più chiaro queste routine KDF e i relativi input:

Metodo ECDiffieHellman Descrizione
DeriveKeyFromHash(ECDiffieHellmanPublicKey, HashAlgorithmName, Byte[], Byte[]) Deriva il materiale della chiave attraverso la formula

HASH(secretPrepend || x || secretAppend)

HASH(secretPrepend OrElse x OrElse secretAppend)

dove x è il risultato calcolato dell'algoritmo ec Diffie-Hellman.
DeriveKeyFromHmac(ECDiffieHellmanPublicKey, HashAlgorithmName, Byte[], Byte[], Byte[]) Deriva il materiale chiave usando la formula

HMAC(hmacKey, secretPrepend || x || secretAppend)

HMAC(hmacKey, secretPrepend oppure x oppure secretAppend)

dove x è il risultato calcolato dell'algoritmo ec Diffie-Hellman.
DeriveKeyTls(ECDiffieHellmanPublicKey, Byte[], Byte[]) Deriva il materiale della chiave usando l'algoritmo di derivazione TLS pseudo-random function (PRF).

supporto per la crittografia simmetrica con chiave persistente

La libreria di crittografia di Windows (CNG) ha aggiunto il supporto per l'archiviazione di chiavi simmetriche persistenti e l'uso di chiavi simmetriche archiviate dall'hardware e .NET Framework 4.6.2 ha consentito agli sviluppatori di usare questa funzionalità. Poiché il concetto di nomi di chiave e provider di chiavi è specifico per l'implementazione, l'uso di questa funzionalità richiede di usare il costruttore dei tipi di implementazione concreti anziché il metodo factory preferito, ad esempio chiamando Aes.Create.

Esiste il supporto della crittografia simmetrica con chiave persistente per gli algoritmi AES (AesCng) e 3DES (TripleDESCng). Per esempio:

public static byte[] EncryptDataWithPersistedKey(byte[] data, byte[] iv)
{
    using (Aes aes = new AesCng("AesDemoKey", CngProvider.MicrosoftSoftwareKeyStorageProvider))
    {
        aes.IV = iv;

        // Using the zero-argument overload is required to make use of the persisted key
        using (ICryptoTransform encryptor = aes.CreateEncryptor())
        {
            if (!encryptor.CanTransformMultipleBlocks)
            {
                throw new InvalidOperationException("This is a sample, this case wasn't handled...");
            }

            return encryptor.TransformFinalBlock(data, 0, data.Length);
        }
    }
}

supporto per SignedXml per l'hashing SHA-2

.NET Framework 4.6.2 aggiunge il supporto alla classe SignedXml per i metodi di firma PKCS#1 RSA-SHA256, RSA-SHA384 e RSA-SHA512 e per gli algoritmi di digest di riferimento SHA256, SHA384 e SHA512.

Le costanti URI sono tutte esposte in SignedXml:

Campo SignedXml Costante
XmlDsigSHA256Url "http://www.w3.org/2001/04/xmlenc#sha256"
XmlDsigRSASHA256Url "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"
XmlDsigSHA384Url "http://www.w3.org/2001/04/xmldsig-more#sha384"
XmlDsigRSASHA384Url "http://www.w3.org/2001/04/xmldsig-more#rsa-sha384"
XmlDsigSHA512Url "http://www.w3.org/2001/04/xmlenc#sha512"
XmlDsigRSASHA512Url "http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"

Tutti i programmi che hanno registrato un gestore di SignatureDescription personalizzato in CryptoConfig per aggiungere il supporto per questi algoritmi continueranno a funzionare come in passato, ma poiché sono ora disponibili impostazioni predefinite della piattaforma, la registrazione CryptoConfig non è più necessaria.

SqlClient

Il provider di dati .NET Framework per SQL Server (System.Data.SqlClient) include le nuove funzionalità seguenti in .NET Framework 4.6.2:

Pool di connessioni e Timeout con database SQL di Azure

Quando il pool di connessioni è abilitato e si verifica un timeout o un altro errore di accesso, viene memorizzata nella cache un'eccezione e l'eccezione memorizzata nella cache viene generata in qualsiasi tentativo di connessione successivo per i successivi 5 secondi a 1 minuto. Per altre informazioni, vedere Pool di Connessioni SQL Server (ADO.NET).

Questo comportamento non è consigliabile quando ci si connette ai database SQL di Azure, poiché i tentativi di connessione possono non riuscire con errori temporanei che vengono in genere ripristinati rapidamente. Per ottimizzare meglio l'esperienza di ripetizione dei tentativi di connessione, il comportamento del periodo di blocco del pool di connessioni viene rimosso quando le connessioni ai database SQL di Azure hanno esito negativo.

L'aggiunta della nuova parola chiave PoolBlockingPeriod consente di selezionare il periodo di blocco più adatto per la tua app. I valori includono:

Auto

Il periodo di blocco del pool di connessioni per un'applicazione che si connette a un database SQL di Azure è disabilitato e il periodo di blocco del pool di connessioni per un'applicazione che si connette a qualsiasi altra istanza di SQL Server è abilitato. Questo è il valore predefinito. Se il nome dell'endpoint server termina con uno dei seguenti, vengono considerati database SQL di Azure:

  • .database.windows.net

  • .database.chinacloudapi.cn

  • .database.usgovcloudapi.net

  • .database.cloudapi.de

AlwaysBlock

Il periodo di blocco del pool di connessioni è sempre abilitato.

NeverBlock

Il periodo di blocco del pool di connessioni è sempre disattivato.

Miglioramenti per Always Encrypted

SQLClient introduce due miglioramenti per Always Encrypted:

  • Per migliorare le prestazioni delle query con parametri sulle colonne di database crittografate, i metadati di crittografia per i parametri di query vengono ora memorizzati nella cache. Con la proprietà SqlConnection.ColumnEncryptionQueryMetadataCacheEnabled impostata su true (ovvero il valore predefinito), se la stessa query viene chiamata più volte, il client recupera i metadati dei parametri dal server una sola volta.

  • Le voci della chiave di crittografia della colonna nella cache delle chiavi vengono rimosse dopo un intervallo di tempo configurabile, impostato usando la proprietà SqlConnection.ColumnEncryptionKeyCacheTtl.

Windows Communication Foundation

In .NET Framework 4.6.2 Windows Communication Foundation è stato migliorato nelle aree seguenti:

supporto per la sicurezza del trasporto WCF per i certificati archiviati tramite CNG

La sicurezza del trasporto WCF supporta i certificati archiviati tramite la libreria di crittografia di Windows (CNG). In .NET Framework 4.6.2 questo supporto è limitato all'uso di certificati con una chiave pubblica con un esponente di lunghezza non superiore a 32 bit. Quando un'applicazione è destinata a .NET Framework 4.6.2, questa funzionalità è attivata per impostazione predefinita.

Per le applicazioni destinate a .NET Framework 4.6.1 e versioni precedenti, ma in esecuzione in .NET Framework 4.6.2, questa funzionalità può essere abilitata aggiungendo la riga seguente alla sezione runtime del file app.config o web.config.

<AppContextSwitchOverrides
    value="Switch.System.IdentityModel.DisableCngCertificates=false"
/>

Questa operazione può essere eseguita anche a livello di codice con codice simile al seguente:

private const string DisableCngCertificates = @"Switch.System.IdentityModel.DisableCngCertificates";
AppContext.SetSwitch(disableCngCertificates, false);

Miglior supporto per più regole di regolazione dell'ora legale nella classe DataContractJsonSerializer

I clienti possono usare un'impostazione di configurazione dell'applicazione per determinare se la classe DataContractJsonSerializer supporta più regole di regolazione per un singolo fuso orario. Si tratta di una funzionalità di consenso esplicito. Per abilitarla, aggiungere l'impostazione seguente al file app.config:

<runtime>
     <AppContextSwitchOverrides value="Switch.System.Runtime.Serialization.DoNotUseTimeZoneInfo=false" />
</runtime>

Quando questa funzionalità è abilitata, un oggetto DataContractJsonSerializer utilizza il tipo di TimeZoneInfo anziché il tipo TimeZone per deserializzare i dati di data e ora. TimeZoneInfo supporta più regole di regolazione, che consentono di lavorare con i dati cronologici del fuso orario; TimeZone non lo fa.

Per altre informazioni sulla struttura di TimeZoneInfo e sulle regolazioni del fuso orario, vedere panoramica del fuso orario .

Migliore corrispondenza NetNamedPipeBinding

WCF ha una nuova impostazione applicativa che può essere configurata nelle applicazioni client per garantire che si connettano sempre al servizio in ascolto sull'URI che meglio corrisponde a quello richiesto. Con questa impostazione dell'app configurata su false (impostazione predefinita), è possibile che i client che usano NetNamedPipeBinding possano tentare di connettersi a un servizio in ascolto su un URI che costituisce una sottostringa dell'URI richiesto.

Ad esempio, un client tenta di connettersi a un servizio in ascolto in net.pipe://localhost/Service1, ma un altro servizio su quella macchina che gira con privilegi di amministratore è in ascolto in net.pipe://localhost. Con questa impostazione dell'app impostata su false, il client tenterebbe di connettersi al servizio errato. Dopo aver impostato l'impostazione dell'app su true, il client si connetterà sempre al servizio di corrispondenza migliore.

Nota

I clienti che usano NetNamedPipeBinding trovano i servizi in base all'indirizzo di base del servizio (se esiste) anziché all'indirizzo endpoint completo. Per assicurarsi che questa impostazione funzioni sempre il servizio deve usare un indirizzo di base univoco.

Per abilitare questa modifica, aggiungere l'impostazione dell'app seguente al file di App.config o Web.config dell'applicazione client:

<configuration>
    <appSettings>
        <add key="wcf:useBestMatchNamedPipeUri" value="true" />
    </appSettings>
</configuration>

SSL 3.0 non è un protocollo predefinito

Quando si usa NetTcp con sicurezza del trasporto e un tipo di credenziale di certificato, SSL 3.0 non è più un protocollo predefinito usato per negoziare una connessione sicura. Nella maggior parte dei casi, non dovrebbe esserci alcun impatto sulle app esistenti, perché TLS 1.0 è incluso nell'elenco di protocolli per NetTcp. Tutti i client esistenti devono essere in grado di negoziare una connessione usando almeno TLS 1.0. Se è necessario Ssl3, usare uno dei meccanismi di configurazione seguenti per aggiungerlo all'elenco dei protocolli negoziati.

Windows Presentation Foundation (WPF)

In .NET Framework 4.6.2 Windows Presentation Foundation è stato migliorato nelle aree seguenti:

Ordinamento del gruppo

Un'applicazione che usa un oggetto CollectionView per raggruppare i dati può ora dichiarare in modo esplicito come ordinare i gruppi. L'ordinamento esplicito risolve il problema dell'ordinamento non intuitivo che si verifica quando un'app aggiunge o rimuove in modo dinamico i gruppi o quando modifica il valore delle proprietà dell'elemento coinvolte nel raggruppamento. Può anche migliorare le prestazioni del processo di creazione del gruppo spostando i confronti delle proprietà di raggruppamento dal tipo di raccolta completa all'ordinamento dei gruppi.

Per supportare l'ordinamento dei gruppi, le nuove proprietà GroupDescription.SortDescriptions e GroupDescription.CustomSort descrivono come ordinare la raccolta di gruppi prodotti dall'oggetto GroupDescription. Questo è analogo al modo in cui le proprietà denominate in modo identico ListCollectionView descrivono come ordinare gli elementi di dati.

Per i casi più comuni, è possibile usare due nuove proprietà statiche della classe PropertyGroupDescription, CompareNameAscending e CompareNameDescending.

Ad esempio, i dati dei gruppi XAML seguenti in base all'età, ordinano i gruppi di età in ordine crescente e raggruppano gli elementi all'interno di ogni fascia di età in base al cognome.

<GroupDescriptions>
     <PropertyGroupDescription
         PropertyName="Age"
         CustomSort=
              "{x:Static PropertyGroupDescription.CompareNamesAscending}"/>
     </PropertyGroupDescription>
</GroupDescriptions>

<SortDescriptions>
     <SortDescription PropertyName="LastName"/>
</SortDescriptions>

supporto della tastiera touch

Il supporto per la tastiera virtuale consente il tracciamento del focus nelle applicazioni WPF richiamando e nascondendo automaticamente la tastiera virtuale in Windows 10 quando il tocco viene ricevuto da un controllo che permette l'immissione di testo.

Nelle versioni precedenti di .NET Framework, le applicazioni WPF non possono scegliere esplicitamente il tracciamento del focus senza disabilitare il supporto dei gesti WPF per il tocco/penna. Di conseguenza, le applicazioni WPF devono scegliere tra il supporto touch completo di WPF o affidarsi alla promozione del mouse di Windows.

DPI per monitor

Per supportare la recente proliferazione di ambienti con valori DPI elevati e DPI ibridi per le app WPF, WPF nel .NET Framework 4.6.2 abilita la consapevolezza per singolo monitor. Per ulteriori informazioni su come rendere la tua app WPF consapevole del DPI per monitor, vedere gli esempi e la guida per sviluppatori su GitHub.

Nelle versioni precedenti di .NET Framework, le app WPF sono consapevoli del DPI di sistema. In altre parole, l'interfaccia utente dell'applicazione viene ridimensionata dal sistema operativo in base alle esigenze, a seconda del valore DPI del monitor su cui viene eseguito il rendering dell'app.

Per le app in esecuzione in .NET Framework 4.6.2, è possibile disabilitare le modifiche DPI per monitor nelle app WPF aggiungendo un'istruzione di configurazione alla sezione <runtime> del file di configurazione dell'applicazione, come indicato di seguito:

<runtime>
   <AppContextSwitchOverrides value="Switch.System.Windows.DoNotScaleForDpiChanges=false"/>
</runtime>

Windows Workflow Foundation (WF)

In .NET Framework 4.6.2 Windows Workflow Foundation è stato migliorato nell'area seguente:

Supporto per espressioni C# e IntelliSense nel Designer WF reospitato

A partire da .NET Framework 4.5, WF supporta espressioni C# sia in Visual Studio Designer che nei flussi di lavoro del codice. La funzionalità chiave del WF, il Designer di flussi di lavoro ospitato esternamente, consente al Designer di flussi di lavoro di essere in un'applicazione fuori da Visual Studio, ad esempio in WPF. Windows Workflow Foundation supporta espressioni C# e IntelliSense nel Designer di flussi di lavoro rehosting. Per ulteriori informazioni, consultare il blog Windows Workflow Foundation.

Availability of IntelliSense when a customer rebuilds a workflow project from Visual Studio Nelle versioni di .NET Framework precedenti alla 4.6.2, WF Designer IntelliSense viene interrotto quando un cliente ricompila un progetto di flusso di lavoro da Visual Studio. Mentre la compilazione del progetto ha esito positivo, i tipi di flusso di lavoro non vengono trovati nella finestra di progettazione e gli avvisi di IntelliSense per i tipi di flusso di lavoro mancanti vengono visualizzati nella finestra elenco errori. .NET Framework 4.6.2 risolve questo problema e rende Disponibile IntelliSense.

Applicazioni Workflow V1 con tracciamento Workflow ora funzionano in modalità FIPS

I computer con la modalità di conformità FIPS abilitata possono ora eseguire correttamente un'applicazione in stile flusso di lavoro versione 1 con rilevamento del flusso di lavoro. Per abilitare questo scenario, è necessario apportare la modifica seguente al file app.config:

<add key="microsoft:WorkflowRuntime:FIPSRequired" value="true" />

Se questo scenario non è abilitato, l'esecuzione dell'applicazione continua a generare un'eccezione con il messaggio "Questa implementazione non fa parte degli algoritmi di crittografia convalidati della piattaforma Windows FIPS".

miglioramenti del flusso di lavoro quando si usa l'aggiornamento dinamico con Progettazione flussi di lavoro di Visual Studio

I designer dei flussi di lavoro, il designer di attività FlowChart e altri designer di attività flusso di lavoro ora caricano e visualizzano con successo i flussi di lavoro salvati dopo aver chiamato il metodo DynamicUpdateServices.PrepareForUpdate. Nelle versioni di .NET Framework precedenti a .NET Framework 4.6.2, il caricamento di un file XAML in Visual Studio per un flusso di lavoro salvato dopo la chiamata DynamicUpdateServices.PrepareForUpdate può causare i problemi seguenti:

  • Il Workflow Designer non riesce a caricare correttamente il file XAML (quando la ViewStateData.Id si trova alla fine della riga).

  • Progettista di Attività del Diagramma di Flusso o altri Progettisti di Attività di Workflow possono visualizzare tutti gli oggetti nelle loro posizioni predefinite invece che nei valori delle proprietà associate.

ClickOnce

ClickOnce è stato aggiornato per supportare TLS 1.1 e TLS 1.2 oltre al protocollo 1.0, che supporta già. ClickOnce rileva automaticamente il protocollo necessario; Non sono necessari passaggi aggiuntivi all'interno dell'applicazione ClickOnce per abilitare il supporto TLS 1.1 e 1.2.

Conversione di app Windows Form e WPF in app UWP

Windows offre ora funzionalità per portare le app desktop di Windows esistenti, incluse le app WPF e Windows Form, alla piattaforma UWP (Universal Windows Platform). Questa tecnologia funge da bridge consentendo di eseguire gradualmente la migrazione della codebase esistente a UWP, portando così l'app a tutti i dispositivi Windows 10.

Le app desktop convertite ottengono un'identità dell'app simile all'identità dell'app UWP, che rende accessibili le API UWP per abilitare funzionalità come riquadri animati e notifiche. L'app continua a comportarsi come prima e viene eseguita come un'app a fiducia completa. Dopo la conversione dell'app, è possibile aggiungere un processo contenitore di app al processo di attendibilità totale esistente per aggiungere un'interfaccia utente adattiva. Quando tutte le funzionalità vengono spostate nel processo del contenitore di app, il processo di attendibilità completa può essere rimosso e la nuova app UWP può essere resa disponibile a tutti i dispositivi Windows 10.

Miglioramenti nel debugging

L'API di debug non gestita è stata migliorata in .NET Framework 4.6.2 per eseguire analisi aggiuntive quando viene generata una NullReferenceException in modo che sia possibile determinare quale variabile in una singola riga di codice sorgente è null. Per supportare questo scenario, sono state aggiunte le API seguenti all'API di debug non gestita.

  • L'ICorDebugCode4, ICorDebugVariableHomee interfacce ICorDebugVariableHomeEnum, che espongono le case native delle variabili gestite. Ciò consente ai debugger di eseguire un'analisi del flusso di codice quando si verifica un NullReferenceException e di lavorare all'indietro per determinare la variabile gestita che corrisponde alla posizione nativa null.

  • Il metodo ICorDebugType2::GetTypeID fornisce un mapping per ICorDebugType a COR_TYPEID, che consente al debugger di ottenere un COR_TYPEID senza un'istanza di ICorDebugType. Le API esistenti in COR_TYPEID possono quindi essere usate per determinare il layout della classe del tipo.

Novità di .NET Framework 4.6.1

.NET Framework 4.6.1 include nuove funzionalità nelle aree seguenti:

Per altre informazioni su .NET Framework 4.6.1, vedere gli argomenti seguenti:

Crittografia: supporto per certificati X509 contenenti ECDSA

.NET Framework 4.6 ha aggiunto il supporto RSACng per i certificati X509. .NET Framework 4.6.1 aggiunge il supporto per i certificati ECDSA (Elliptic Curve Digital Signature Algorithm) X509.

ECDSA offre prestazioni migliori ed è un algoritmo di crittografia più sicuro rispetto a RSA, offrendo una scelta eccellente in cui le prestazioni e la scalabilità di Transport Layer Security (TLS) sono un problema. L'implementazione di .NET Framework esegue il wrapping delle chiamate nelle funzionalità di Windows esistenti.

Il codice di esempio seguente illustra quanto sia semplice generare una firma per un flusso di byte usando il nuovo supporto per i certificati ECDSA X509 inclusi in .NET Framework 4.6.1.

using System;
using System.Security.Cryptography;
using System.Security.Cryptography.X509Certificates;

public class Net461Code
{
    public static byte[] SignECDsaSha512(byte[] data, X509Certificate2 cert)
    {
        using (ECDsa privateKey = cert.GetECDsaPrivateKey())
        {
            return privateKey.SignData(data, HashAlgorithmName.SHA512);
        }
    }

    public static byte[] SignECDsaSha512(byte[] data, ECDsa privateKey)
    {
        return privateKey.SignData(data, HashAlgorithmName.SHA512);
    }
}

Ciò offre un netto contrasto rispetto al codice necessario per generare una firma in .NET Framework 4.6.

using System;
using System.Security.Cryptography;
using System.Security.Cryptography.X509Certificates;

public class Net46Code
{
    public static byte[] SignECDsaSha512(byte[] data, X509Certificate2 cert)
    {
        // This would require using cert.Handle and a series of p/invokes to get at the
        // underlying key, then passing that to a CngKey object, and passing that to
        // new ECDsa(CngKey).  It's a lot of work.
        throw new Exception("That's a lot of work...");
    }

    public static byte[] SignECDsaSha512(byte[] data, ECDsa privateKey)
    {
        // This way works, but SignData probably better matches what you want.
        using (SHA512 hasher = SHA512.Create())
        {
            byte[] signature1 = privateKey.SignHash(hasher.ComputeHash(data));
        }

        // This might not be the ECDsa you got!
        ECDsaCng ecDsaCng = (ECDsaCng)privateKey;
        ecDsaCng.HashAlgorithm = CngAlgorithm.Sha512;
        return ecDsaCng.SignData(data);
    }
}

ADO.NET

A ADO.NET sono stati aggiunti gli elementi seguenti:

Supporto Always Encrypted per le chiavi protette da hardware

ADO.NET supporta ora l'archiviazione di chiavi master della colonna Always Encrypted in modo nativo nei moduli di protezione hardware. Con questo supporto, i clienti possono sfruttare le chiavi asimmetriche archiviate nell'HSM senza dover scrivere provider di archiviazione personalizzati per chiavi master di colonna e registrarli nelle applicazioni.

I clienti devono installare il provider CSP fornito dal fornitore dell'HSM o i provider dell'archivio chiavi CNG, sui server delle applicazioni o sui computer client, per accedere ai dati Always Encrypted protetti con chiavi master di colonna archiviate in un HSM.

Miglioramento del comportamento di connessione MultiSubnetFailover per AlwaysOn

SqlClient ora fornisce automaticamente connessioni più veloci a un gruppo di disponibilità AlwaysOn (AG). Rileva in modo trasparente se l'applicazione si connette a un gruppo di disponibilità AlwaysOn in una subnet diversa e individua rapidamente il server attivo, fornendo una connessione al server. Prima di questa versione, un'applicazione doveva impostare la stringa di connessione per includere "MultisubnetFailover=true" per indicare che si connetteva a un gruppo di disponibilità AlwaysOn. Senza impostare la parola chiave di connessione su true, un'applicazione potrebbe riscontrare un timeout durante la connessione a un gruppo di disponibilità AlwaysOn. Con questa versione, un'applicazione non necessario impostare MultiSubnetFailover più su true. Per ulteriori informazioni sul supporto di SqlClient per i gruppi di disponibilità Always On, vedere Supporto SqlClient per l'alta disponibilità e il ripristino di emergenza.

Windows Presentation Foundation (WPF)

Windows Presentation Foundation include numerosi miglioramenti e modifiche.

miglioramento delle prestazioni

Il ritardo nell'attivazione degli eventi di tocco è stato risolto in .NET Framework 4.6.1. Inoltre, la digitazione in un controllo RichTextBox non blocca più il processo di rendering durante l'input rapido.

miglioramenti del controllo ortografico

Il correttore ortografico in WPF è stato aggiornato in Windows 8.1 e versioni successive per sfruttare il supporto del sistema operativo per il controllo ortografico aggiuntivo. Non sono state apportate modifiche alle funzionalità nelle versioni di Windows precedenti a Windows 8.1.

Come nelle versioni precedenti di .NET Framework, il linguaggio per un controllo TextBox o un blocco RichTextBox viene rilevato cercando informazioni nell'ordine seguente:

  • xml:lang, se è presente.

  • Lingua di input corrente.

  • Cultura attuale.

Per altre informazioni sul supporto del linguaggio in WPF, vedere il post di blog WPF sulle funzionalità di .NET Framework 4.6.1.

Supporto aggiuntivo per i dizionari personalizzati per utente

In .NET Framework 4.6.1 WPF riconosce i dizionari personalizzati registrati a livello globale. Questa funzionalità è disponibile, oltre alla possibilità di registrarle individualmente per ciascun controllo.

Nelle versioni precedenti di WPF, i dizionari personalizzati non riconoscevano le parole escluse e gli elenchi di correzione automatica. Sono supportati in Windows 8.1 e Windows 10 tramite l'uso di file che possono essere inseriti nella directory %AppData%\Microsoft\Spelling\<language tag>. Le regole seguenti si applicano a questi file:

  • I file devono avere estensioni con estensione dic (per parole aggiunte), .exc (per parole escluse) o acl (per correzione automatica).

  • I file devono essere testo non crittografato UTF-16 LE che inizia con byte Order Mark (BOM).

  • Ogni riga deve essere costituita da una parola (negli elenchi di parole aggiunte ed escluse) o da una coppia di correzioni automatiche con le parole separate da una barra verticale ("|") (nell'elenco di correzioni automatiche).

  • Questi file sono considerati di sola lettura e non vengono modificati dal sistema.

Nota

Questi nuovi formati di file non sono supportati direttamente dalle API di controllo ortografico WPF e i dizionari personalizzati forniti a WPF nelle applicazioni devono continuare a usare file con estensione lex.

esempi di

Sono disponibili diversi esempi WPF nel repository Microsoft/WPF-Samples GitHub. Aiutaci a migliorare i nostri esempi inviandoci una pull request o segnalando un problema su GitHub .

estensioni DirectX

WPF include un pacchetto NuGet che fornisce nuove implementazioni di D3DImage che semplificano l'interoperabilità con il contenuto DX10 e Dx11. Il codice per questo pacchetto è stato open source ed è disponibile in GitHub.

Windows Workflow Foundation: Transazioni

Il metodo Transaction.EnlistPromotableSinglePhase può ora usare un gestore di transazioni distribuite diverso da MSDTC per promuovere la transazione. Si può fare specificando un identificatore del promotore di transazione GUID per il nuovo overload Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid). Se l'operazione ha esito positivo, esistono limitazioni relative alle funzionalità della transazione. Dopo l'integrazione di un promotore di transazione non MSDTC, i metodi seguenti generano un TransactionPromotionException perché questi metodi richiedono l'innalzamento di livello a MSDTC:

Una volta arruolato un promotore di transazioni diverso da MSDTC, deve essere utilizzato per le future partecipazioni durevoli tramite i protocolli che esso definisce. Il Guid del promotore della transazione può essere ottenuto utilizzando la proprietà PromoterType. Quando la transazione viene promossa, il promotore della transazione fornisce un array di Byte che rappresenta il token promosso. Un'applicazione può ottenere il token promozionato per una transazione promossa non-MSDTC con il metodo GetPromotedToken.

Gli utenti del nuovo overload Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid) devono seguire una sequenza di chiamata specifica affinché l'operazione di promozione venga completata correttamente. Queste regole sono documentate nella documentazione del metodo.

Profilatura

L'API di profilatura non gestita è stata migliorata come segue:

  • Supporto migliore per l'accesso ai PDB nell'interfaccia ICorProfilerInfo7.

    In ASP.NET Core, sta diventando molto più comune che gli assembly vengano compilati in memoria da Roslyn. Per gli sviluppatori che creano strumenti di profilatura, ciò significa che i PDB che storicamente sono stati serializzati su disco potrebbero non essere più presenti. Gli strumenti del profiler spesso utilizzano i PDB per mappare il codice alle righe di origine per attività quali copertura del codice o analisi delle prestazioni riga per riga. L'interfaccia ICorProfilerInfo7 include ora due nuovi metodi, ICorProfilerInfo7::GetInMemorySymbolsLength e ICorProfilerInfo7::ReadInMemorySymbols, per fornire a questi strumenti del profiler l'accesso ai dati PDB in memoria, Usando le nuove API, un profiler può ottenere il contenuto di un PDB in memoria come matrice di byte e quindi elaborarlo o serializzarlo su disco.

  • Migliore strumentazione con l'interfaccia ICorProfiler.

    I profiler che usano la funzionalità ReJit delle API di ICorProfiler per la strumentazione dinamica possono ora modificare alcuni metadati. In precedenza tali strumenti potevano instrumentare IL in qualsiasi momento, ma i metadati potevano essere modificati solo in fase di caricamento del modulo. Poiché IL fa riferimento ai metadati, questo limita i tipi di strumentazione che possono essere eseguiti. Alcuni di questi limiti sono stati elevati aggiungendo il metodo ICorProfilerInfo7::ApplyMetaData per supportare un subset di modifiche ai metadati dopo il caricamento del modulo, in particolare aggiungendo nuovi record AssemblyRef, TypeRef, TypeSpec, MemberRef, MemberSpece UserString. Questa modifica rende possibile una gamma molto più ampia di strumentazione on-the-fly.

Generatore di immagini native (NGEN) PDBs

La tracciatura di eventi tra macchine consente ai clienti di effettuare la profilazione di un programma sulla Macchina A ed esaminare i dati di profilazione con la mappatura delle righe di origine sulla Macchina B. Usando le versioni precedenti del .NET Framework, l'utente copiava tutti i moduli e le immagini native dalla macchina profilata alla macchina di analisi che possiede il PDB IL per creare la mappatura da origine a nativo. Anche se questo processo può funzionare bene quando i file sono relativamente piccoli, ad esempio per le applicazioni telefoniche, i file possono essere molto grandi nei sistemi desktop e richiedono molto tempo per la copia.

Con i PDB di Ngen, NGen può creare un PDB contenente il mapping da IL a nativo senza una dipendenza dal PDB IL. Nello scenario di traccia degli eventi tra computer, tutto ciò che è necessario è copiare il PDB dell'immagine nativa generato dal computer A nel computer B e usare API di accesso all'interfaccia di debug per leggere il mapping di origine del PDB DEL PDB, il mappingto-IL e il mapping nativo del PDB da il a nativo dell'immagine. La combinazione di entrambe le mappature fornisce una mappatura da origine a nativa. Poiché il PDB dell'immagine nativa è molto più piccolo di tutti i moduli e le immagini native, il processo di copia dal computer A al computer B è molto più veloce.

Novità di .NET 2015

.NET 2015 introduce .NET Framework 4.6 e .NET Core. Alcune nuove funzionalità si applicano sia al .NET Framework 4.6 che a .NET Core, mentre altre funzionalità sono specifiche di ciascuno di essi.

  • ASP.NET Core

    .NET 2015 include ASP.NET Core, un'implementazione .NET snella per la creazione di app moderne basate sul cloud. ASP.NET Core è modulare in modo da poter includere solo le funzionalità necessarie nell'applicazione. Può essere ospitato in IIS o self-hosted in un processo personalizzato ed è possibile eseguire app con versioni diverse di .NET Framework nello stesso server. Include un nuovo sistema di configurazione dell'ambiente progettato per la distribuzione cloud.

    MVC, API Web e Pagine Web vengono unificati in un singolo framework denominato MVC 6. È possibile compilare ASP.NET app Core tramite strumenti in Visual Studio 2015 o versione successiva. Le applicazioni esistenti funzioneranno sul nuovo .NET Framework; Tuttavia, per compilare un'app che usa MVC 6 o SignalR 3, è necessario usare il sistema di progetto in Visual Studio 2015 o versione successiva.

    Per informazioni, vedere ASP.NET Core.

  • Aggiornamenti ASP.NET

    • API basata su compiti per lo svuotamento asincrono della risposta

      ASP.NET offre ora una semplice API basata su attività per lo scaricamento asincrono delle risposte, HttpResponse.FlushAsync, che consente di scaricare le risposte in modo asincrono usando il supporto async/await del linguaggio.

    • l'associazione di modelli supporta i metodi di restituzione delle attività

      Nella .NET Framework 4.5, ASP.NET ha aggiunto la funzionalità di associazione modello che abilita un approccio estensibile, centrato sul codice per le operazioni sui dati basate su CRUD nelle pagine Web Forms e nei controlli utente. Il sistema di associazione di modelli ora supporta metodi di associazione che restituiscono Task. Questa funzionalità consente agli sviluppatori di Web Form di ottenere i vantaggi di scalabilità di async con la facilità del sistema di data binding quando si usano versioni più recenti di ORM, incluso Entity Framework.

      L'associazione di modelli asincroni è controllata dall'impostazione di configurazione aspnet:EnableAsyncModelBinding.

      <appSettings>
          <add key=" aspnet:EnableAsyncModelBinding" value="true|false" />
      </appSettings>
      

      Nelle app che utilizzano .NET Framework 4.6, l'impostazione predefinita è true. Nelle app in esecuzione in .NET Framework 4.6 destinate a una versione precedente di .NET Framework, è false per impostazione predefinita. Può essere abilitata impostando l'impostazione di configurazione su true.

    • supporto HTTP/2 (Windows 10)

      HTTP/2 è una nuova versione del protocollo HTTP che offre un utilizzo della connessione molto migliore (meno round-trip tra client e server), con conseguente riduzione della latenza nel caricamento delle pagine web per gli utenti. Le pagine Web (anziché i servizi) traggono il massimo vantaggio da HTTP/2, poiché il protocollo ottimizza per più artefatti richiesti come parte di una singola esperienza. Il supporto HTTP/2 è stato aggiunto a ASP.NET in .NET Framework 4.6. Poiché la funzionalità di rete esiste a più livelli, sono state necessarie nuove funzionalità in Windows, in IIS e in ASP.NET per abilitare HTTP/2. Devi essere in esecuzione in Windows 10 per usare HTTP/2 con ASP.NET.

      HTTP/2 è supportato anche e attivato per impostazione predefinita per le app UWP (Universal Windows Platform) di Windows 10 che usano l'API System.Net.Http.HttpClient.

      Per consentire l'uso della funzionalità di PUSH_PROMISE nelle applicazioni ASP.NET, è stato aggiunto un nuovo metodo con due overload, PushPromise(String) e PushPromise(String, String, NameValueCollection), alla classe HttpResponse.

      Nota

      Anche se ASP.NET Core supporta HTTP/2, il supporto per la funzionalità PUSH PROMISE non è ancora stato aggiunto.

      Il browser e il server Web (IIS in Windows) eseguono tutte le operazioni. Non devi fare alcuno sforzo pesante per i tuoi utenti.

      La maggior parte dei principali browser supporta HTTP/2, quindi è probabile che gli utenti possano trarre vantaggio dal supporto HTTP/2 se il server lo supporta.

    • Supporto per il Protocollo Token Binding

      Microsoft e Google hanno collaborato a un nuovo approccio all'autenticazione, denominato Token Binding Protocol. Il presupposto è che i token di autenticazione (nella cache del browser) possono essere rubati e usati dai criminali per accedere a risorse altrimenti sicure (ad esempio, il conto bancario) senza richiedere la password o altre informazioni privilegiate. Il nuovo protocollo mira a mitigare questo problema.

      Il protocollo di associazione token verrà implementato in Windows 10 come funzionalità del browser. ASP.NET le applicazioni parteciperanno al protocollo, in modo che i token di autenticazione vengano convalidati come legittimi. Le implementazioni del client e del server stabiliscono la protezione end-to-end specificata dal protocollo.

    • algoritmi di hash delle stringhe randomizzati

      .NET Framework 4.5 ha introdotto un algoritmo di hash casuale per le stringhe . Tuttavia, non è supportato da ASP.NET a causa del fatto che alcune delle funzionalità di ASP.NET dipendono da un codice hash stabile. In .NET Framework 4.6 sono ora supportati algoritmi hash di stringa casuali. Per abilitare questa funzionalità, usare l'impostazione di configurazione aspnet:UseRandomizedStringHashAlgorithm.

      <appSettings>
          <add key="aspnet:UseRandomizedStringHashAlgorithm" value="true|false" />
      </appSettings>
      
  • ADO.NET

    ADO .NET supporta ora la funzionalità Always Encrypted disponibile in SQL Server 2016. Con Always Encrypted, SQL Server può eseguire operazioni sui dati crittografati e, soprattutto, la chiave di crittografia risiede con l'applicazione all'interno dell'ambiente attendibile del cliente e non nel server. Always Encrypted protegge i dati dei clienti in modo che gli amministratori di database non abbiano accesso ai dati di testo normale. La crittografia e la decrittografia dei dati vengono eseguite in modo trasparente a livello di driver, riducendo al minimo le modifiche che devono essere apportate alle applicazioni esistenti. Per informazioni dettagliate, vedere Always Encrypted (Motore di database) e Always Encrypted (sviluppo client).

  • il compilatore JIT a 64 bit per codice gestito

    .NET Framework 4.6 include una nuova versione del compilatore JIT a 64 bit (originariamente denominato RyuJIT). Il nuovo compilatore a 64 bit offre miglioramenti significativi delle prestazioni rispetto al compilatore JIT a 64 bit precedente. Il nuovo compilatore a 64 bit è abilitato per i processi a 64 bit in esecuzione su .NET Framework 4.6. L'app verrà eseguita in un processo a 64 bit se viene compilata come a 64 bit o AnyCPU ed è in esecuzione in un sistema operativo a 64 bit. Sebbene sia stata eseguita la transizione al nuovo compilatore il più trasparente possibile, è possibile apportare modifiche al comportamento.

    Il nuovo compilatore JIT a 64 bit include anche funzionalità di accelerazione SIMD hardware quando utilizzato con tipi abilitati per SIMD nello spazio dei nomi System.Numerics, che possono produrre buoni miglioramenti delle prestazioni.

  • I miglioramenti del caricatore di assembly

    Il caricatore di assembly ora utilizza la memoria in modo più efficiente rilasciando gli assembly IL dopo il caricamento di un'immagine NGEN corrispondente. Questa modifica riduce la memoria virtuale, particolarmente utile per le app a 32 bit di grandi dimensioni (ad esempio Visual Studio) e salva anche la memoria fisica.

  • modifiche apportate alla libreria di classi di base

    Molte nuove API sono state aggiunte a .NET Framework 4.6 per abilitare scenari chiave. Di seguito sono riportate le modifiche e le aggiunte seguenti:

    • IReadOnlyCollection<T> implementazioni

      Le raccolte aggiuntive implementano IReadOnlyCollection<T>, ad esempio Queue<T> e Stack<T>.

    • CultureInfo.CurrentCulture e CultureInfo.CurrentUICulture

      Le proprietà CultureInfo.CurrentCulture e CultureInfo.CurrentUICulture sono ora di lettura/scrittura anziché di sola lettura. Se si assegna un nuovo oggetto CultureInfo a queste proprietà, anche la cultura del thread corrente definita dalla proprietà Thread.CurrentThread.CurrentCulture e la cultura del thread dell'interfaccia utente corrente definita dalla proprietà Thread.CurrentThread.CurrentUICulture cambiano.

    • miglioramenti apportati a Garbage Collection (GC)

      La classe GC include ora metodi TryStartNoGCRegion e EndNoGCRegion che consentono di impedire l'operazione di Garbage Collection durante l'esecuzione di un percorso critico.

      Un nuovo overload del metodo GC.Collect(Int32, GCCollectionMode, Boolean, Boolean) consente di controllare se l'heap di oggetti di piccole dimensioni e l'heap di oggetti di grandi dimensioni vengono spazzati e compattati o solo spazzati.

    • tipi abilitati per SIMD

      Lo spazio dei nomi System.Numerics include ora diversi tipi con supporto SIMD, ad esempio Matrix3x2, Matrix4x4, Plane, Quaternion, Vector2, Vector3e Vector4.

      Poiché il nuovo compilatore JIT a 64 bit include anche funzionalità di accelerazione SIMD hardware, esistono miglioramenti significativi delle prestazioni quando si usano i tipi abilitati per SIMD con il nuovo compilatore JIT a 64 bit.

    • aggiornamenti della crittografia

      L'API System.Security.Cryptography viene aggiornata per supportare le API di crittografia CNG di Windows . Le versioni precedenti di .NET Framework si sono affidate interamente a una versione precedente delle API di crittografia di Windows come base per l'implementazione System.Security.Cryptography. Sono state richieste per supportare l'API CNG, poiché supporta moderni algoritmi di crittografia, importanti per determinate categorie di app.

      .NET Framework 4.6 include i nuovi miglioramenti seguenti per supportare le API di crittografia CNG di Windows:

      • Set di metodi di estensione per certificati X509, System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(System.Security.Cryptography.X509Certificates.X509Certificate2) e System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(System.Security.Cryptography.X509Certificates.X509Certificate2), che restituiscono un'implementazione basata su CNG anziché un'implementazione basata su CAPI, quando possibile. Alcune smart card e così via richiedono comunque CAPI e le API gestiscono il fallback.

      • Classe System.Security.Cryptography.RSACng, che fornisce un'implementazione CNG dell'algoritmo RSA.

      • Miglioramenti all'API RSA in modo che le azioni comuni non richiedano più il cast. Ad esempio, la crittografia dei dati con un oggetto X509Certificate2 richiede codice simile al seguente nelle versioni precedenti di .NET Framework.

        RSACryptoServiceProvider rsa = (RSACryptoServiceProvider)cert.PrivateKey;
        byte[] oaepEncrypted = rsa.Encrypt(data, true);
        byte[] pkcs1Encrypted = rsa.Encrypt(data, false);
        

        Il codice che usa le nuove API di crittografia in .NET Framework 4.6 può essere riscritto come indicato di seguito per evitare il cast.

        RSA rsa = cert.GetRSAPrivateKey();
        if (rsa == null)
           throw new InvalidOperationException("An RSA certificate was expected");
        
        byte[] oaepEncrypted = rsa.Encrypt(data, RSAEncryptionPadding.OaepSHA1);
        byte[] pkcs1Encrypted = rsa.Encrypt(data, RSAEncryptionPadding.Pkcs1);
        
    • Supporto per la conversione di date e orari da o verso l'ora Unix

      Alla struttura di DateTimeOffset sono stati aggiunti i nuovi metodi seguenti per supportare la conversione dei valori di data e ora in o dall'ora Unix:

    • Interruttori di compatibilità

      La classe AppContext aggiunge una nuova funzionalità di compatibilità che consente agli autori di librerie di fornire un meccanismo di opt-out uniforme per le nuove funzionalità per i loro utenti. Stabilisce un contratto ad accoppiamento debole tra i componenti per comunicare una richiesta di esclusione. Questa funzionalità è in genere importante quando viene apportata una modifica alla funzionalità esistente. Al contrario, esiste già un consenso esplicito implicito per le nuove funzionalità.

      Con AppContext, le librerie definiscono ed espongono commutatori di compatibilità, mentre il codice che dipende da essi può impostare tali opzioni per influire sul comportamento della libreria. Per impostazione predefinita, le librerie forniscono le nuove funzionalità e le modificano solo (ovvero forniscono la funzionalità precedente) se l'opzione è impostata.

      Un'applicazione (o una libreria) può dichiarare il valore di un'opzione (che è sempre un valore Boolean) definita da una libreria dipendente. L'opzione è sempre implicitamente false. Impostando l'interruttore su true esso viene abilitato. L'impostazione esplicita del commutatore su false genera il nuovo comportamento.

      AppContext.SetSwitch("Switch.AmazingLib.ThrowOnException", true);
      

      La libreria deve verificare se un consumatore ha dichiarato il valore dell'interruttore e quindi agire di conseguenza.

      if (!AppContext.TryGetSwitch("Switch.AmazingLib.ThrowOnException", out shouldThrow))
      {
          // This is the case where the switch value was not set by the application.
          // The library can choose to get the value of shouldThrow by other means.
          // If no overrides nor default values are specified, the value should be 'false'.
          // A false value implies the latest behavior.
      }
      
      // The library can use the value of shouldThrow to throw exceptions or not.
      if (shouldThrow)
      {
          // old code
      }
      else
      {
          // new code
      }
      

      È utile usare un formato coerente per gli interruttori, poiché sono un contratto formale esposto da una libreria. Di seguito sono riportati due formati ovvi.

      • switch.spazio dei nomi.switchname

      • switch.libreria.switchname

    • Modifiche al modello asincrono basato sulle attività (TAP)

      Per le app destinate a .NET Framework 4.6, gli oggetti Task e Task<TResult> ereditano le impostazioni culturali e quelle dell'interfaccia utente del thread chiamante. Il comportamento delle app destinate a versioni precedenti di .NET Framework o che non sono destinate a una versione specifica di .NET Framework non è interessato. Per ulteriori informazioni, vedere la sezione "Cultura e operazioni asincrone basate su attività" dell'argomento relativo alla classe CultureInfo.

      La classe System.Threading.AsyncLocal<T> consente di rappresentare i dati di ambiente locali per un determinato flusso di controllo asincrono, ad esempio un metodo async. Può essere usato per rendere persistenti i dati tra thread. È anche possibile definire un metodo di callback che riceve una notifica ogni volta che i dati di ambiente cambiano perché la proprietà AsyncLocal<T>.Value è stata modificata in modo esplicito o perché il thread ha rilevato una transizione di contesto.

      Sono stati aggiunti tre metodi pratici, Task.CompletedTask, Task.FromCancelede Task.FromException, al modello asincrono basato su attività (TAP) per restituire le attività completate in uno stato specifico.

      La classe NamedPipeClientStream supporta ora la comunicazione asincrona con il nuovo ConnectAsync. metodo.

    • EventSource supporta ora la scrittura nel registro eventi

      È ora possibile usare la classe EventSource per registrare messaggi amministrativi o operativi nel registro eventi, oltre a qualsiasi sessione ETW esistente creata nel computer. In passato era necessario usare il pacchetto NuGet Microsoft.Diagnostics.Tracing.EventSource per questa funzionalità. Questa funzionalità è ora incorporata in .NET Framework 4.6.

      Sia il pacchetto NuGet che .NET Framework 4.6 sono stati aggiornati con le funzionalità seguenti:

      • eventi dinamici

        Consente gli eventi definiti "in tempo reale" senza creare metodi di evento.

      • payload avanzati

        Consente di passare come payload classi e matrici con attributi specifici, nonché tipi primitivi

      • Rilevamento delle attività

        Fa in modo che gli eventi Start e Stop contrassegnino gli eventi tra di essi con un ID che rappresenta tutte le attività attualmente attive.

      Per supportare queste funzionalità, il metodo Write sovraccarico è stato aggiunto alla classe EventSource.

  • Windows Presentation Foundation (WPF)

    • miglioramenti di HDPI

      Il supporto HDPI in WPF è ora migliore in .NET Framework 4.6. Sono state apportate modifiche all'arrotondamento del layout per ridurre i casi di ritaglio nei controlli con bordi. Per impostazione predefinita, questa funzionalità è abilitata solo se il TargetFrameworkAttribute è impostato su .NET Framework 4.6. Le applicazioni destinate alle versioni precedenti del framework ma in esecuzione in .NET Framework 4.6 possono acconsentire esplicitamente al nuovo comportamento aggiungendo la riga seguente alla sezione runtime del file app.config:

      <AppContextSwitchOverrides
      value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=false"
      />
      

      Le finestre WPF che si estendono su più monitor con impostazioni DPI diverse (configurazione multi-DPI) vengono ora renderizzate completamente senza aree nere. È possibile rifiutare esplicitamente questo comportamento aggiungendo la riga seguente alla sezione <appSettings> del file app.config per disabilitare questo nuovo comportamento:

      <add key="EnableMultiMonitorDisplayClipping" value="true"/>
      

      Il supporto per il caricamento automatico del cursore destro in base all'impostazione DPI è stato aggiunto a System.Windows.Input.Cursor.

    • Touch è migliore

      I report dei clienti su Connect riguardo al fatto che il tocco produce comportamenti imprevedibili sono stati risolti nel .NET Framework 4.6. La soglia di doppio tocco per le applicazioni Windows Store e le applicazioni WPF è ora la stessa in Windows 8.1 e versioni successive.

    • Supporto per finestre figlio trasparenti

      WPF in .NET Framework 4.6 supporta finestre figlie trasparenti in Windows 8.1 e versioni successive. In questo modo è possibile creare finestre figlio non rettangolari e trasparenti nelle finestre di primo livello. È possibile abilitare questa funzionalità impostando la proprietà HwndSourceParameters.UsesPerPixelTransparency su true.

  • Windows Communication Foundation (WCF)

    • supporto SSL

      WCF supporta ora i protocolli TLS 1.1 e TLS 1.2, oltre a SSL 3.0 e TLS 1.0, quando si usa NetTcp con la sicurezza del trasporto e l'autenticazione client. È ora possibile selezionare il protocollo da usare o disabilitare i protocolli meno sicuri meno vecchi. Questa operazione può essere eseguita impostando la proprietà SslProtocols o aggiungendo quanto segue a un file di configurazione.

      <netTcpBinding>
          <binding>
            <security mode= "None|Transport|Message|TransportWithMessageCredential" >
                <transport clientCredentialType="None|Windows|Certificate"
                          protectionLevel="None|Sign|EncryptAndSign"
                          sslProtocols="Ssl3|Tls1|Tls11|Tls12">
                  </transport>
            </security>
          </binding>
      </netTcpBinding>
      
    • Invio di messaggi con connessioni HTTP diverse

      WCF consente ora agli utenti di assicurarsi che determinati messaggi vengano inviati usando connessioni HTTP sottostanti diverse. Esistono due modi per eseguire questa operazione:

      • Uso di un prefisso del nome del gruppo di connessioni

        Gli utenti possono specificare una stringa che WCF userà come prefisso per il nome del gruppo di connessioni. Due messaggi con prefissi diversi vengono inviati usando connessioni HTTP sottostanti diverse. Per impostare il prefisso, aggiungere una coppia chiave/valore alla proprietà Message.Properties del messaggio. La chiave è "HttpTransportConnectionGroupNamePrefix"; il valore è il prefisso desiderato.

      • Uso di channel factory diverse

        Gli utenti possono anche abilitare una funzionalità che garantisce che i messaggi inviati tramite canali creati da channel factory diverse usino connessioni HTTP sottostanti diverse. Per abilitare questa funzionalità, gli utenti devono impostare il appSetting seguente su true:

        <appSettings>
            <add key="wcf:httpTransportBinding:useUniqueConnectionPoolPerFactory" value="true" />
        </appSettings>
        
  • Windows Workflow Foundation (WWF)

    È ora possibile specificare il numero di secondi per i quali un servizio di flusso di lavoro manterrà una richiesta di operazione fuori ordine quando è presente un segnalibro "non protocollo" in attesa, prima che la richiesta vada in timeout. Un segnalibro "non protocollo" è un segnalibro non associato alle attività di ricezione aperte. Alcune attività creano segnalibri non di protocollo all'interno dell'implementazione, quindi potrebbe non essere ovvio che esiste un segnalibro non protocollo. Questi includono State e Pick. Pertanto, se si dispone di un servizio di flusso di lavoro implementato con una macchina a stati o contenente un'attività Pick, è probabile che siano presenti segnalibri non di protocollo. È possibile specificare l'intervallo aggiungendo una riga simile alla seguente alla sezione appSettings del file app.config:

    <add key="microsoft:WorkflowServices:FilterResumeTimeoutInSeconds" value="60"/>
    

    Il valore predefinito è 60 secondi. Se value è impostato su 0, le richieste non ordinate vengono immediatamente rifiutate con un errore con testo simile al seguente:

    Operation 'Request3|{http://tempuri.org/}IService' on service instance with identifier '2b0667b6-09c8-4093-9d02-f6c67d534292' cannot be performed at this time. Please ensure that the operations are performed in the correct order and that the binding in use provides ordered delivery guarantees.
    

    Si tratta dello stesso messaggio ricevuto se viene ricevuto un messaggio di operazione non in ordine e non sono presenti segnalibri non di protocollo.

    Se il valore dell'elemento FilterResumeTimeoutInSeconds è diverso da zero, sono presenti segnalibri non di protocollo e l'intervallo di timeout scade, l'operazione ha esito negativo con un messaggio di timeout.

  • transazioni

    È ora possibile includere l'identificatore della transazione distribuita che ha causato la generazione di un'eccezione derivata da TransactionException. A tale scopo, aggiungere la chiave seguente alla sezione appSettings del file app.config:

    <add key="Transactions:IncludeDistributedTransactionIdInExceptionMessage" value="true"/>
    

    Il valore predefinito è false.

  • Rete

    • riutilizzo del socket

      Windows 10 include un nuovo algoritmo di rete a scalabilità elevata che consente di usare meglio le risorse del computer riutilizzando le porte locali per le connessioni TCP in uscita. .NET Framework 4.6 supporta il nuovo algoritmo, consentendo alle app .NET di sfruttare il nuovo comportamento. Nelle versioni precedenti di Windows era presente un limite di connessione simultaneo artificiale (in genere 16.384, le dimensioni predefinite dell'intervallo di porte dinamiche), che poteva limitare la scalabilità di un servizio causando l'esaurimento delle porte quando è in carico.

      In .NET Framework 4.6 sono state aggiunte due API per abilitare il riutilizzo delle porte, che rimuove in modo efficace il limite di 64 KB per le connessioni simultanee:

      Per impostazione predefinita, la proprietà ServicePointManager.ReusePort è false a meno che il valore HWRPortReuseOnSocketBind della chiave del Registro di sistema HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 sia impostato su 0x1. Per abilitare il riutilizzo delle porte locali nelle connessioni HTTP, impostare la proprietà ServicePointManager.ReusePort su true. In questo modo tutte le connessioni socket TCP in uscita da HttpClient e HttpWebRequest usano una nuova opzione socket di Windows 10, SO_REUSE_UNICASTPORT, che consente il riutilizzo delle porte locali.

      Gli sviluppatori che scrivono un'applicazione basata solo su socket possono specificare l'opzione System.Net.Sockets.SocketOptionName al momento di chiamare un metodo come Socket.SetSocketOption in modo che i socket in uscita riutilizzino la porta locale durante il binding.

    • Supporto per i nomi di dominio internazionali e PunyCode

      Una nuova proprietà, IdnHost, è stata aggiunta alla classe Uri per supportare meglio i nomi di dominio internazionali e PunyCode.

  • Ridimensionamento nei controlli Windows Forms.

    Questa funzionalità è stata espansa in .NET Framework 4.6 per includere i tipi DomainUpDown, NumericUpDown, DataGridViewComboBoxColumn, DataGridViewColumn e ToolStripSplitButton e il rettangolo specificato dalla proprietà Bounds utilizzata per disegnare un UITypeEditor.

    Si tratta di una funzionalità di consenso esplicito. Per abilitarla, impostare l'elemento EnableWindowsFormsHighDpiAutoResizing su true nel file di configurazione dell'applicazione (app.config) :

    <appSettings>
        <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" />
    </appSettings>
    
  • supporto per le codifiche della tabella codici

    .NET Core supporta principalmente le codifiche Unicode e per impostazione predefinita offre un supporto limitato per le codifiche della tabella codici. È possibile aggiungere il supporto per le codifiche della tabella codici disponibili in .NET Framework, ma non supportate in .NET Core registrando le codifiche della tabella codici con il metodo Encoding.RegisterProvider. Per altre informazioni, vedere System.Text.CodePagesEncodingProvider.

  • .NET Native

Le app UWP (Universal Windows Platform) scritte in C# o Visual Basic possono sfruttare una nuova tecnologia che compila le app in codice nativo anziché in IL. Questa tecnologia produce app con tempi di avvio e esecuzione più veloci. Per altre informazioni, vedere Compilazione di app con .NET Native. Per una panoramica su .NET Native che analizza le differenze rispetto alla compilazione JIT e a NGEN e cosa significa per il tuo codice, vedere .NET Native e Compilation.

Le app vengono compilate in codice nativo per impostazione predefinita quando vengono compilate con Visual Studio 2015 o versione successiva. Per altre informazioni, vedere Introduzione a .NET Native.

Per supportare il debug di app .NET Native, sono state aggiunte diverse nuove interfacce ed enumerazioni all'API di debug non gestita. Per ulteriori informazioni, vedere l'argomento Debugging (Riferimento API non gestite).

  • pacchetti .NET Framework open source

    I pacchetti .NET Core, ad esempio le raccolte non modificabili, le API SIMD e le API di rete, ad esempio quelle presenti nello spazio dei nomi System.Net.Http, sono ora disponibili come pacchetti open source in GitHub. Per accedere al codice, vedere .NET in GitHub. Per ulteriori informazioni e su come contribuire a questi pacchetti, consultare Introduzione a .NET, Home Page di .NET su GitHub.

Novità di .NET Framework 4.5.2

  • Nuove API per le app di ASP.NET. I nuovi metodi HttpResponse.AddOnSendingHeaders e HttpResponseBase.AddOnSendingHeaders consentono di esaminare e modificare le intestazioni di risposta e il codice di stato man mano che la risposta viene inviata all'app client. Prendere in considerazione l'uso di questi metodi anziché degli eventi PreSendRequestHeaders e PreSendRequestContent; sono più efficienti e affidabili.

    Il metodo HostingEnvironment.QueueBackgroundWorkItem consente di pianificare piccoli elementi di lavoro in background. ASP.NET tiene traccia di questi elementi e impedisce a IIS di terminare bruscamente il processo di lavoro fino al completamento di tutti gli elementi di lavoro in background. Questo metodo non può essere chiamato all'esterno di un dominio app gestito ASP.NET.

    Le nuove proprietà HttpResponse.HeadersWritten e HttpResponseBase.HeadersWritten restituiscono valori booleani che indicano se le intestazioni di risposta sono state scritte. È possibile usare queste proprietà per garantire che le chiamate alle API, ad esempio HttpResponse.StatusCode (che generano eccezioni se le intestazioni sono state scritte), abbiano esito positivo.

  • Ridimensionamento nei controlli Windows Forms. Questa funzionalità è stata espansa. È ora possibile usare l'impostazione DPI di sistema per ridimensionare i componenti dei controlli aggiuntivi seguenti(ad esempio, la freccia a discesa nelle caselle combinate):

    Si tratta di una funzionalità di consenso esplicito. Per abilitarla, impostare l'elemento EnableWindowsFormsHighDpiAutoResizing su true nel file di configurazione dell'applicazione (app.config) :

    <appSettings>
        <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" />
    </appSettings>
    
  • Nuova funzionalità del flusso di lavoro. Un gestore di risorse che usa il metodo EnlistPromotableSinglePhase (e pertanto implementa l'interfaccia IPromotableSinglePhaseNotification) può usare il nuovo metodo Transaction.PromoteAndEnlistDurable per richiedere quanto segue:

    Questa operazione può essere eseguita all'interno dello stesso dominio dell'app e non richiede alcun codice aggiuntivo non gestito per interagire con MSDTC per eseguire la promozione. Il nuovo metodo può essere chiamato solo quando esiste una richiesta pendente da System.Transactions al metodo IPromotableSinglePhaseNotificationPromote implementato dalla partecipazione promuovibile.

  • Miglioramenti della profilazione. Le nuove API di profilatura non gestite seguenti offrono una profilatura più affidabile:

    Le precedenti implementazioni di ICorProfiler supportavano il caricamento differito degli assembly dipendenti. Le nuove API di profilatura richiedono che gli assembly dipendenti inseriti dal profiler siano caricabili immediatamente, anziché essere caricati dopo l'inizializzazione completa dell'app. Questa modifica non influisce sugli utenti delle API di ICorProfiler esistenti.

  • Miglioramenti del debug. Le nuove API di debug non gestite seguenti offrono una migliore integrazione con un profiler. È ora possibile accedere ai metadati inseriti dal profiler, nonché alle variabili locali e al codice prodotto dalle richieste ReJIT del compilatore durante il debug del dump.

  • Modifiche alla traccia eventi. .NET Framework 4.5.2 abilita il tracciamento delle attività out-of-process basato su Event Tracing for Windows (ETW) per un ambito più ampio. Ciò consente ai fornitori di APM (Advanced Power Management) di fornire strumenti leggeri che tengono traccia accuratamente dei costi delle singole richieste e attività che intersecano i thread. Questi eventi vengono generati solo quando i controller ETW li abilitano; pertanto, le modifiche non influiscono sul codice ETW scritto in precedenza o sul codice eseguito con ETW disabilitato.

  • Promozione di una transazione e conversione in un arruolamento durevole

    Transaction.PromoteAndEnlistDurable è una nuova API aggiunta a .NET Framework 4.5.2 e 4.6:

    [System.Security.Permissions.PermissionSetAttribute(System.Security.Permissions.SecurityAction.LinkDemand, Name = "FullTrust")]
    public Enlistment PromoteAndEnlistDurable(Guid resourceManagerIdentifier,
                                              IPromotableSinglePhaseNotification promotableNotification,
                                              ISinglePhaseNotification enlistmentNotification,
                                              EnlistmentOptions enlistmentOptions)
    

    Il metodo può essere usato da un arruolamento che è stato creato in precedenza da Transaction.EnlistPromotableSinglePhase in risposta al metodo ITransactionPromoter.Promote. Chiede a System.Transactions di promuovere la transazione a una transazione MSDTC e di "convertire" l'arruolamento promuovibile in un arruolamento durevole. Al termine di questo metodo, l'interfaccia IPromotableSinglePhaseNotification non verrà più referenziata da System.Transactionse le notifiche future arriveranno sull'interfaccia ISinglePhaseNotification fornita. L'arruolamento in questione deve fungere da arruolamento durevole, supportando la registrazione e il recupero delle transazioni. Per informazioni dettagliate, vedere Transaction.EnlistDurable. Inoltre, l'arruolamento deve supportare ISinglePhaseNotification. Questo metodo può chiamare solo durante l'elaborazione di una chiamata ITransactionPromoter.Promote. In caso contrario, viene generata un'eccezione TransactionException.

Novità di .NET Framework 4.5.1

Gli aggiornamenti di aprile 2014:

  • Visual Studio 2013 Update 2 include aggiornamenti ai modelli della libreria di classi portabile per supportare questi scenari:

    • È possibile usare le API di Windows Runtime nelle librerie portabili destinate a Windows 8.1, Windows Phone 8.1 e Windows Phone Silverlight 8.1.

    • Puoi includere XAML (tipi Windows.UI.XAML) nelle librerie portabili quando hai come destinazione Windows 8.1 o Windows Phone 8.1. Sono supportati i modelli XAML seguenti: pagina vuota, dizionario risorse, controllo basato su modelli e controllo utente.

    • Puoi creare un componente Windows Runtime portatile (file con estensione winmd) da usare nelle app dello Store destinate a Windows 8.1 e Windows Phone 8.1.

    • È possibile ridefinire una libreria di classi di Windows Store o Windows Phone Store, ad esempio una libreria di classi portabile.

    Per altre informazioni su queste modifiche, vedere libreria di classi portabile.

  • Il set di contenuto .NET Framework include ora la documentazione per .NET Native, che è una tecnologia di precompilazione per la compilazione e la distribuzione di app di Windows. .NET Native compila le app direttamente nel codice nativo, anziché nel linguaggio intermedio (IL), per ottenere prestazioni migliori. Per informazioni dettagliate, vedere Compilazione di app con .NET Native.

  • L'origine di riferimento di .NET Framework offre una nuova esperienza di esplorazione e funzionalità avanzate. È ora possibile esplorare online il codice sorgente di .NET Framework, scaricare il riferimento per la visualizzazione offline ed esaminare passo passo le origini (incluse patch e aggiornamenti) durante il debug. Per ulteriori informazioni, vedere la voce di blog Un nuovo look per la sorgente di riferimento .NET.

Le nuove funzionalità e i miglioramenti delle classi di base in .NET Framework 4.5.1 includono:

  • Reindirizzamento automatico del collegamento per le assembly. A partire da Visual Studio 2013, quando si compila un'app destinata a .NET Framework 4.5.1, è possibile aggiungere reindirizzamenti di binding al file di configurazione dell'app se l'app o i relativi componenti fanno riferimento a più versioni dello stesso assembly. È anche possibile abilitare questa funzionalità per i progetti destinati a versioni precedenti di .NET Framework. Per altre informazioni, vedere Procedura: Abilitare e disabilitare il reindirizzamento automatico dell'associazione.

  • Possibilità di raccogliere informazioni di diagnostica per aiutare gli sviluppatori a migliorare le prestazioni delle applicazioni server e cloud. Per altre informazioni, vedere i metodi WriteEventWithRelatedActivityId e WriteEventWithRelatedActivityIdCore nella classe EventSource.

  • Possibilità di compattare in modo esplicito l'heap di oggetti di grandi dimensioni durante l'operazione di Garbage Collection. Per ulteriori informazioni, consultare la proprietà GCSettings.LargeObjectHeapCompactionMode.

  • Miglioramenti aggiuntivi delle prestazioni, come la sospensione dell'app ASP.NET, i miglioramenti JIT multi-core e un avvio più rapido dell'app dopo un aggiornamento di .NET Framework. Per informazioni dettagliate, vedere l'annuncio di .NET Framework 4.5.1 e il post del blog sulla sospensione delle app ASP.NET .

I miglioramenti apportati a Windows Form includono:

  • Ridimensionamento nei controlli Windows Forms. È possibile usare l'impostazione DPI di sistema per ridimensionare i componenti dei controlli, ad esempio le icone visualizzate in una griglia delle proprietà, attivando un'opzione nel file di configurazione dell'applicazione (app.config) per l'app. Questa funzionalità è attualmente supportata nei controlli Windows Form seguenti:

    Per abilitare questa funzionalità, aggiungere un nuovo elemento><appSettings al file di configurazione (app.config) e impostare l'elemento EnableWindowsFormsHighDpiAutoResizing su true:

    <appSettings>
        <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" />
    </appSettings>
    

I miglioramenti apportati al debug delle app .NET Framework in Visual Studio 2013 includono:

  • Restituisce valori nel debugger di Visual Studio. Quando si esegue il debug di un'app gestita in Visual Studio 2013, nella finestra Auto vengono visualizzati i tipi restituiti e i valori per i metodi. Queste informazioni sono disponibili per le app desktop, Windows Store e Windows Phone. Per altre informazioni, vedere Esaminare i valori restituiti delle chiamate al metodo.

  • Modificare e continuare per le app a 64 bit. Visual Studio 2013 supporta la funzionalità Modifica e continuazione per le app gestite a 64 bit per desktop, Windows Store e Windows Phone. Le limitazioni esistenti rimangono in vigore sia per le app a 32 bit che per quelle a 64 bit (vedere l'ultima sezione dell'articolo Modifiche del Codice Supportate (C#)).

  • Debug con riconoscimento asincrono. Per semplificare il debug di app asincrone in Visual Studio 2013, lo stack di chiamate nasconde il codice dell'infrastruttura fornito dai compilatori per supportare la programmazione asincrona e include anche i frame padre logici per poter seguire più chiaramente l'esecuzione logica del programma. Una finestra Attività sostituisce la finestra Attività parallele e visualizza le attività correlate a un punto di interruzione specifico e visualizza anche tutte le altre attività attualmente attive o pianificate nell'app. Puoi leggere di questa funzionalità nella sezione "Debugging consapevole dell'asincronia" dell'annuncio di .NET Framework 4.5.1.

  • Supporto migliore delle eccezioni per i componenti Windows Runtime. In Windows 8.1, le eccezioni che derivano dalle app di Windows Store mantengono informazioni sull'errore che ha causato l'eccezione, anche attraverso i limiti della lingua. Puoi leggere informazioni su questa funzionalità nella sezione "Sviluppo delle app di Windows Store" dell'annuncio di .NET Framework 4.5.1.

A partire da Visual Studio 2013, è possibile usare lo strumento di ottimizzazione guidata del profilo gestito (Mpgo.exe) per ottimizzare le app di Windows 8.x Store e le app desktop.

Per le nuove funzionalità in ASP.NET 4.5.1, vedere le Note sulla Versione di ASP.NET e Strumenti Web per Visual Studio 2013.

Novità di .NET Framework 4.5

Classi di base

  • Possibilità di ridurre i riavvii del sistema rilevando e chiudendo le applicazioni .NET Framework 4 durante la distribuzione. Fare riferimento a Riduzione dei riavvii del sistema durante le installazioni di .NET Framework 4.5.

  • Supporto per matrici di dimensioni superiori a 2 gigabyte (GB) su piattaforme a 64 bit. Questa funzionalità può essere abilitata nel file di configurazione dell'applicazione. Vedere l'elemento <gcAllowVeryLargeObjects>, che elenca anche altre restrizioni relative alle dimensioni degli oggetti e alle dimensioni della matrice.

  • Migliori prestazioni attraverso la raccolta dei rifiuti in background per i server. Quando si usa Garbage Collection del server in .NET Framework 4.5, l'operazione di Garbage Collection in background viene abilitata automaticamente. Consulta la sezione Background Server Garbage Collection dell'argomento Fundamentals of Garbage Collection.

  • Compilazione JIT (Just-In-Time) disponibile come opzione in background nei processori multi-core per migliorare le prestazioni delle applicazioni. Vedi ProfileOptimization.

  • Possibilità di limitare per quanto tempo il motore delle espressioni regolari tenterà di risolvere un'espressione regolare prima del timeout. Vedere la proprietà Regex.MatchTimeout.

  • Possibilità di definire la cultura predefinita per un dominio applicativo. Vedere la classe CultureInfo.

  • Supporto della console per la codifica Unicode (UTF-16). Vedere la classe Console.

  • Supporto per il versionamento dei dati di ordinamento e confronto delle stringhe culturali. Vedere la classe SortVersion.

  • Prestazioni migliori durante il recupero delle risorse. Consultare Pacchetti e distribuzione di risorse.

  • Miglioramenti della compressione zip per ridurre le dimensioni di un file compresso. Consulta lo spazio dei nomi System.IO.Compression.

  • Possibilità di personalizzare un contesto di reflection per eseguire l'override del comportamento di reflection predefinito tramite la classe CustomReflectionContext.

  • Supporto per la versione 2008 dello standard Internationalized Domain Names in Applications (IDNA) quando la classe System.Globalization.IdnMapping viene usata su Windows 8.

  • Delegare il confronto tra stringhe al sistema operativo, che implementa Unicode 6.0, quando il .NET Framework viene utilizzato su Windows 8. Quando viene eseguito su altre piattaforme, il .NET Framework include i propri dati di confronto di stringhe, che implementano Unicode 5.x. Vedere la classe String e la sezione Osservazioni della classe SortVersion.

  • Possibilità di calcolare i codici hash per le stringhe in base al dominio dell'applicazione. Vedere <UseRandomizedStringHashAlgorithm elemento>.

  • Il supporto della riflessione dei tipi è suddiviso tra le classi Type e TypeInfo. Consultare Reflection nel .NET Framework per le app Windows Store.

Managed Extensibility Framework (MEF) - Framework per l'estensibilità gestita

In .NET Framework 4.5, Managed Extensibility Framework (MEF) offre le nuove funzionalità seguenti:

  • Supporto per i tipi generici.

  • Modello di programmazione basato su convenzioni che consente di creare parti in base alle convenzioni di denominazione anziché agli attributi.

  • Molteplici ambiti.

  • Subset di MEF che puoi usare quando crei app di Windows 8.x Store. Questo subset è disponibile come pacchetto scaricabile dalla galleria NuGet. Per installare il pacchetto, apri il tuo progetto in Visual Studio, quindi scegli Gestisci pacchetti NuGet dal menu Progetto e cerca online il pacchetto Microsoft.Composition.

Per ulteriori informazioni, vedere Managed Extensibility Framework (MEF).

Operazioni di file asincrone

In .NET Framework 4.5 sono state aggiunte nuove funzionalità asincrone ai linguaggi C# e Visual Basic. Queste funzionalità aggiungono un modello basato su attività per l'esecuzione di operazioni asincrone. Per usare questo nuovo modello, usare i metodi asincroni nelle classi di I/O. Vedi I/O di file asincroni.

Strumenti

In il .NET Framework 4.5, il Generatore di File di Risorse (Resgen.exe) consente di creare un file .resw da usare nelle app di Windows 8.x Store da un file .resources incorporato in un assembly .NET Framework. Per altre informazioni, vedere Resgen.exe (generatore di file di risorse).

L'Ottimizzazione Guidata dal Profilo Gestito (Mpgo.exe) consente di migliorare il tempo di avvio dell'applicazione, l'utilizzo della memoria (dimensioni del set di lavoro) e il rendimento ottimizzando gli assembly di immagini native. Lo strumento da riga di comando genera i dati del profilo per gli assembly dell'applicazione immagine nativa. Vedere Mpgo.exe (Strumento di Ottimizzazione Guidata Profili Gestiti). A partire da Visual Studio 2013, puoi usare Mpgo.exe per ottimizzare le app di Windows 8.x Store e le app desktop.

Elaborazione parallela

.NET Framework 4.5 offre diverse nuove funzionalità e miglioramenti per il calcolo parallelo. Sono incluse prestazioni migliorate, maggiore controllo, supporto migliorato per la programmazione asincrona, una nuova libreria di flussi di dati e supporto migliorato per il debug parallelo e l'analisi delle prestazioni. Vedere la voce What's New for Parallelism in .NET Framework 4.5 nel blog Di programmazione parallela con .NET.

Web

ASP.NET 4.5 e 4.5.1 aggiungere l'associazione di modelli per Web Form, supporto WebSocket, gestori asincroni, miglioramenti delle prestazioni e molte altre funzionalità. Per altre informazioni, vedere le risorse seguenti:

Codice del networking

.NET Framework 4.5 offre una nuova interfaccia di programmazione per le applicazioni HTTP. Per ulteriori informazioni, consultare i nuovi namespace System.Net.Http e System.Net.Http.Headers.

È incluso anche il supporto per una nuova interfaccia di programmazione per l'accettazione e l'interazione con una connessione WebSocket tramite le classi HttpListener esistenti e correlate. Per altre informazioni, vedere il nuovo spazio dei nomi System.Net.WebSockets e la classe HttpListener.

.NET Framework 4.5 include inoltre i miglioramenti di rete seguenti:

  • Supporto URI conforme a RFC. Per altre informazioni, vedere Uri e classi correlate.

  • Supporto per il parsing degli IDN (Internationalized Domain Name). Per altre informazioni, vedere Uri e classi correlate.

  • Supporto per l'internazionalizzazione degli indirizzi di posta elettronica (EAI). Per ulteriori informazioni, consultare lo spazio dei nomi System.Net.Mail.

  • Supporto IPv6 migliorato. Per ulteriori informazioni, vedere il namespace System.Net.NetworkInformation.

  • Supporto socket a doppia modalità. Per altre informazioni, vedere le classi Socket e TcpListener.

Windows Presentation Foundation (WPF)

In .NET Framework 4.5 Windows Presentation Foundation (WPF) contiene modifiche e miglioramenti nelle aree seguenti:

  • Il nuovo controllo Ribbon che consente di implementare un'interfaccia utente della barra multifunzione che ospita una Toolbar di Accesso Rapido, un menu dell'applicazione e schede.

  • Nuova interfaccia INotifyDataErrorInfo, che supporta la convalida sincrona e asincrona dei dati.

  • Nuove funzionalità per le classi VirtualizingPanel e Dispatcher.

  • Miglioramento delle prestazioni durante la visualizzazione di grandi set di dati raggruppati e l'accesso a raccolte su thread non appartenenti all'interfaccia utente.

  • Associazione dati a proprietà statiche, associazione dati a tipi personalizzati che implementano l'interfaccia ICustomTypeProvider e recupero delle informazioni sull'associazione dati da un'espressione di associazione.

  • Riposizionamento dei dati durante la modifica dei valori (shaping in tempo reale).

  • Possibilità di verificare se il contesto dati di un contenitore di elementi sia disconnesso.

  • Possibilità di impostare l'intervallo di tempo che deve trascorrere tra le modifiche alle proprietà e gli aggiornamenti dell'origine dati.

  • Miglioramento del supporto per l'implementazione di modelli di eventi deboli. Inoltre, gli eventi possono ora accettare estensioni di markup.

Windows Communication Foundation (WCF)

In .NET Framework 4.5 sono state aggiunte le funzionalità seguenti per semplificare la scrittura e la gestione di applicazioni Windows Communication Foundation (WCF):

  • Semplificazione dei file di configurazione generati.

  • Supporto per lo sviluppo basato sul contratto.

  • Capacità di configurare più facilmente la modalità di compatibilità di ASP.NET.

  • Modifiche ai valori predefiniti delle proprietà di trasporto per ridurre la probabilità che sia necessario impostarle.

  • Aggiornamenti alla classe XmlDictionaryReaderQuotas per ridurre la probabilità che sia necessario configurare manualmente le quote per i lettori di dizionario XML.

  • Convalida dei file di configurazione WCF da Visual Studio come parte del processo di compilazione, in modo da poter rilevare gli errori di configurazione prima di eseguire l'applicazione.

  • Nuovo supporto per lo streaming asincrono.

  • Nuova mappatura del protocollo HTTPS per semplificare l'esposizione di un endpoint attraverso HTTPS con Internet Information Services (IIS).

  • Possibilità di generare metadati in un singolo documento WSDL aggiungendo ?singleWSDL all'URL del servizio.

  • Supporto WebSockets per abilitare la comunicazione realmente bidirezionale sulle porte 80 e 443 con caratteristiche di prestazioni simili al trasporto TCP.

  • Supporto per la configurazione dei servizi nel codice.

  • Suggerimenti dell'editor XML.

  • supporto per la cache ChannelFactory.

  • Supporto della compressione del codificatore binario.

  • Supporto per un trasporto UDP che consente agli sviluppatori di scrivere servizi che usano la messaggistica "fire and forget". Un client invia un messaggio a un servizio e non prevede alcuna risposta dal servizio.

  • Possibilità di supportare più modalità di autenticazione in un singolo endpoint WCF quando si usa il trasporto HTTP e la sicurezza del trasporto.

  • Supporto per i servizi WCF che usano nomi di dominio internazionalizzati (IDN).

Per altre informazioni, vedere Novità in Windows Communication Foundation.

Windows Workflow Foundation (WF)

In .NET Framework 4.5 sono state aggiunte diverse nuove funzionalità a Windows Workflow Foundation (WF), tra cui:

  • Flussi di lavoro delle macchine a stati, introdotti per la prima volta come parte di .NET Framework 4.0.1 (.NET Framework 4 Platform Update 1). Questo aggiornamento includeva diverse nuove classi e attività che consentivano agli sviluppatori di creare flussi di lavoro delle macchine a stati. Queste classi e attività sono state aggiornate per .NET Framework 4.5 per includere:

    • Possibilità di impostare punti di interruzione sugli stati.

    • Possibilità di copiare e incollare transizioni nella finestra di progettazione del flusso di lavoro.

    • Supporto del designer per la creazione di transizioni con trigger condiviso.

    • Attività per la creazione di flussi di lavoro della macchina a stati, tra cui: StateMachine, Statee Transition.

  • Funzionalità avanzate di Progettazione flussi di lavoro, ad esempio le seguenti:

    • Funzionalità migliorate di ricerca nei flussi di lavoro in Visual Studio, tra cui Trova rapidamente e Trova nei file.

    • Possibilità di creare automaticamente un'attività di tipo Sequence quando viene aggiunta una seconda attività figlia a un'attività contenitore e includere automaticamente entrambe le attività nel tipo di attività Sequence.

    • Supporto per la panoramica, che consente di modificare la parte visibile di un flusso di lavoro senza usare le barre di scorrimento.

    • Una nuova visualizzazione Struttura Documento che mostra i componenti di un flusso di lavoro in una visualizzazione ad albero e consente di selezionare un componente nella visualizzazione Struttura Documento .

    • Possibilità di aggiungere annotazioni alle attività.

    • Possibilità di definire e utilizzare delegati di attività tramite la finestra di progettazione del flusso di lavoro.

    • Connessione e inserimento automatici per attività e transizioni nei flussi di lavoro basati su macchine a stati e diagrammi di flusso.

  • Archiviazione delle informazioni sullo stato di visualizzazione per un flusso di lavoro in un singolo elemento nel file XAML, in modo da poter individuare e modificare facilmente le informazioni sullo stato di visualizzazione.

  • Un'attività contenitore NoPersistScope per impedire la persistenza delle attività figlie.

  • Supporto per le espressioni C#:

    • I progetti flusso di lavoro che usano Visual Basic useranno espressioni di Visual Basic e i progetti di flusso di lavoro C# useranno espressioni C#.

    • I progetti del flusso di lavoro C# creati in Visual Studio 2010 e con espressioni Visual Basic sono compatibili con i progetti flusso di lavoro C# che usano espressioni C#.

  • Miglioramenti del versionamento:

    • Nuova classe WorkflowIdentity, che fornisce un mapping tra un'istanza del flusso di lavoro persistente e la relativa definizione del flusso di lavoro.

    • Esecuzione parallela di più versioni del flusso di lavoro nello stesso host, incluso WorkflowServiceHost.

    • In Aggiornamento dinamico, è possibile modificare la definizione di un'istanza di flusso di lavoro persistente.

  • Sviluppo del servizio basato su contratto, che fornisce supporto per la generazione automatica di attività per corrispondere a un contratto di servizio esistente.

Per altre informazioni, vedere Novità su Windows Workflow Foundation.

.NET per le app di Windows 8.x Store

Le app di Windows 8.x Store sono progettate per fattori di forma specifici e sfruttano la potenza del sistema operativo Windows. Un subset di .NET Framework 4.5 o 4.5.1 è disponibile per la compilazione di app di Windows 8.x Store per Windows tramite C# o Visual Basic. Questo sottoinsieme è denominato .NET per le app di Windows 8.x Store ed è descritto in una panoramica .

Librerie di classi portabili

Il progetto Libreria di classi portabile in Visual Studio 2012 (e versioni successive) consente di scrivere e compilare assembly gestiti che funzionano su più piattaforme .NET Framework. Usando un progetto Libreria di classi portabile, scegli le piattaforme (ad esempio Windows Phone e .NET per le app di Windows 8.x Store) come destinazione. I tipi e i membri disponibili nel progetto vengono automaticamente limitati ai tipi e ai membri comuni in queste piattaforme. Per ulteriori informazioni, consulta la Libreria di classi portatili.

Vedere anche