Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Nota
.NET Framework viene gestito in modo indipendente dagli aggiornamenti Windows con correzioni di bug di sicurezza e affidabilità. In generale, gli aggiornamenti della sicurezza vengono rilasciati trimestralmente. .NET Framework continuerà a essere incluso con Windows, senza piani per rimuoverlo. Non è necessario eseguire la migrazione delle app di .NET Framework, ma per un nuovo sviluppo usare .NET anziché .NET Framework.
Questo articolo riepiloga le nuove funzionalità e i miglioramenti principali nelle versioni seguenti di .NET Framework:
- .NET Framework 4.8.1
- .NET Framework 4.8
- .NET Framework 4.7.2
- .NET Framework 4.7.1
- .NET Framework 4.7
- .NET Framework 4.6.2
- .NET Framework 4.6.1
- .NET 2015 e .NET Framework 4.6
- .NET Framework 4.5.2
- .NET Framework 4.5.1
- .NET Framework 4.5
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 API e librerie di classi aggiuntive e .NET Framework e rilasci fuori banda. Consultare l'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:
- programma di installazione Web di .NET Framework 4.8.1
- programma di installazione offline di NET Framework 4.8.1
.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 indirizzare .NET Framework 4.8.1 in Visual Studio 2022 17.3 o versioni successive installando il pacchetto di sviluppo di .NET Framework 4.8.1.
Novità di .NET Framework 4.8.1
.NET Framework 4.8.1 introduce nuove funzionalità nelle aree seguenti:
- Supporto nativo per Arm64
- suggerimenti accessibili conformi a WCAG2.1
- Windows Forms - Miglioramenti dell'accessibilità
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 A 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 Windows, entrambe che forniscono agli sviluppatori il supporto necessario per creare applicazioni accessibili. Nelle ultime versioni, sia Windows Forms 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 Forms questo supporto è disponibile solo nei sistemi operativi Windows 11 o versioni successive. Windows Forms è un sottile wrapper gestito attorno all'API di Windows e il nuovo comportamento del tooltip è diventato disponibile solo in Windows 11. WPF non ha dipendenze dalla versione del sistema operativo per le descrizioni comando accessibili.
WPF ha implementato la maggior parte dei requisiti per i tooltip conformi a WCAG2.1 in .NET Framework 4.8. In questa versione, WPF ha migliorato l'esperienza assicurandosi che una descrizione comando nella finestra corrente possa essere facilmente chiusa usando il tasto Esc, il tasto Ctrl (da solo) o la combinazione Ctrl+Shift+F10. 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 Forms è stato il primo stack di interfaccia utente 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 Forms ha risolto diversi problemi. Per un elenco completo delle modifiche correlate all'accessibilità, visitare A novità dell'accessibilità in .NET Framework.
I punti salienti dei miglioramenti Windows Forms in .NET Framework 4.8.1 sono:
Supporto del modello 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 Forms aggiunto questo supporto per TextBox, celle DataGridView, controlli ComboBox e altro ancora.
Risolvere i problemi di contrasto: in diversi controlli, Windows Forms ha 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:
programma di installazione Web di .NET Framework 4.8
.NET Framework 4.8 può essere installato in Windows 10, Windows 8.1, Windows 7 SP1 e le 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 specificare come destinazione .NET Framework 4.8 in Visual Studio 2012 o versione successiva installando .NET Framework 4.8 Developer Pack.
Novità di .NET Framework 4.8
.NET Framework 4.8 introduce nuove funzionalità nelle aree seguenti:
- classi base
- Windows Communication Foundation (WCF)
- Windows Presentation Foundation (WPF)
- Ambiente di esecuzione comune
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 le novità sull'accessibilità in .NET Framework.
classi base
Riduzione dell'impatto FIPS sulla crittografia. Nelle versioni precedenti di .NET Framework, le classi del provider di crittografia gestito, ad esempio SHA256Managed, generavano un'eccezione CryptographicException quando le librerie di crittografia di sistema erano 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:
- MD5Cng
- MD5CryptoServiceProvider
- RC2CryptoServiceProvider
- RijndaelManaged
- RIPEMD160Managed
- SHA256Managed
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 Switch.System.Security.Cryptography.UseLegacyFipsThrow AppContext 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 .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);Dim host As New ServiceHost(GetType(Service1), New Uri("http://contoso:81/Service1")) Dim healthBehavior As ServiceHealthBehavior = host.Description.Behaviors.Find(Of ServiceHealthBehavior)() If healthBehavior Is Nothing Then healthBehavior = New ServiceHealthBehavior() End If 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, OnDispatcherFailureOnListenerFailure, , OnThrottlePercentExceedede un codice di risposta HTTP può essere specificato 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:
In caso di errore del servizio:
https://contoso:81/Service1?health&OnServiceFailure=450Viene restituito un codice di stato della risposta HTTP 450 quando ServiceHost.State è maggiore di CommunicationState.Opened.
Parametri ed esempi di query:
OnDispatcherFailure:
https://contoso:81/Service1?health&OnDispatcherFailure=455Viene 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=465Viene restituito un codice di stato della risposta HTTP 465 quando lo stato di uno dei listener di canale è maggiore di CommunicationState.Opened.
SuPercentualeAcceleratoreSuperata:
https://contoso:81/Service1?health&OnThrottlePercentExceeded= 70:350,95:500Specifica 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 la consapevolezza dpi Per-Monitor V2 e la scalabilità DPI Mixed-Mode. Per altre informazioni sullo sviluppo di applicazioni dpi elevate, vedere Sviluppo di applicazioni desktop DPI Windows.
.NET Framework 4.8 migliora il supporto per gli HWND ospitati e l'interoperabilità con Windows Forms nelle applicazioni High-DPI WPF su piattaforme che supportano il ridimensionamento DPI a modalità mista (a partire dall'Aggiornamento di aprile 2018 di Windows 10). Quando i controlli HWND o Windows Forms ospitati vengono creati come finestre scalate in modalità DPI mista chiamando SetThreadDpiHostingBehavior e SetThreadDpiAwarenessContext, possono ospitarli in un'applicazione Per-Monitor V2 WPF 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 la modalità di consapevolezza DPI Per-Monitor v2 consente anche di ospitare controlli WPF, ovvero inseriti come elemento 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>
Ambiente di esecuzione 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 di 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 le immagini del Generatore di Immagini Native (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 Assembly.Load(Byte[]) metodo , 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 Antimalware Scan Interface (AMSI).
Novità di .NET Framework 4.7.2
.NET Framework 4.7.2 include nuove funzionalità nelle aree seguenti:
Un obiettivo continuativo in .NET Framework 4.7.2 è il miglioramento dell'accessibilità, che consente a un'applicazione di offrire un'esperienza adeguata agli utenti di tecnologie assistive. Per informazioni sui miglioramenti dell'accessibilità in .NET Framework 4.7.2, vedere Novità sull'accessibilità in .NET Framework.
classi base
.NET Framework 4.7.2 include un numero elevato di miglioramenti crittografici, un migliore supporto per la decompressione per gli archivi ZIP e altre API di raccolta.
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.
}
' Before .NET Framework 4.7.2
Using rsa = RSA.Create()
rsa.ImportParameters(rsaParameters)
' Other code to execute using the rsa instance.
End Using
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.
}
' Starting with .NET Framework 4.7.2
Using rsa = RSA.Create(rsaParameters)
' Other code to execute using the rsa instance.
End Using
I DSA.Create(Int32) metodi e RSA.Create(Int32) consentono di generare chiavi nuove DSA o RSA con dimensioni specifiche della chiave. Per esempio:
using (DSA dsa = DSA.Create(2048))
{
// Other code to execute using the dsa instance.
}
Using dsa = DSA.Create(2048)
' Other code to execute using the dsa instance.
End Using
I costruttori Rfc2898DeriveBytes accettano il nome dell'algoritmo hash
La Rfc2898DeriveBytes classe ha tre nuovi costruttori con un HashAlgorithmName parametro 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);
}
}
Private Shared Function DeriveKey(password As String, ByRef iterations As Integer,
ByRef salt AS Byte(), ByRef algorithm As HashAlgorithmName) As Byte()
iterations = 100000
algorithm = HashAlgorithmName.SHA256
Const SaltSize As Integer = 32
Const DerivedValueSize As Integer = 32
Using pbkdf2 = New Rfc2898DeriveBytes(password, SaltSize, iterations, algorithm)
salt = pbkdf2.Salt
Return pbkdf2.GetBytes(DerivedValueSize)
End Using
End Function
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 X509Certificate2.PrivateKey proprietà 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 consente 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 blog.
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à per determinare l'algoritmo di System.Security.Cryptography.Pkcs.SignerInfo.SignatureAlgorithm 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 ha un costruttore aggiuntivo che consente a Dispose di non chiudere il flusso di cui è stato eseguito il wrapping. 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);
Dim 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 native Windows per impostazione predefinita. In genere, ciò comporta un miglioramento sostanziale delle prestazioni.
Il supporto per la decompressione tramite Windows API è abilitato per impostazione predefinita per le applicazioni destinate a .NET Framework 4.7.2. Le applicazioni destinate a versioni precedenti di .NET Framework ma sono in esecuzione in .NET Framework 4.7.2 possono acconsentire esplicitamente a questo comportamento aggiungendo il seguente AppContext switch 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:
TryGetValuemetodi, che estendono il modello try usato in altri tipi di raccolta a questi due tipi. I metodi sono:Enumerable.To*metodi di estensione, che convertono una raccolta in un HashSet<T>:Nuovi costruttori HashSet<T> che consentono di impostare la capacità della raccolta, che offre un vantaggio in termini di prestazioni quando si conoscono le dimensioni del HashSet<T> in anticipo:
- hashset pubblico (capacità int)
- pubblico HashSet(int capacity, IEqualityComparer<T> comparer)
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)
Public AddOrUpdate(Of TArg)(key As TKey, addValueFactory As Func(Of TKey, TArg, TValue), updateValueFactory As Func(Of TKey, TValue, TArg, TValue), factoryArgument As TArg) As TValue
Public GetOrAdd(Of TArg)(key As TKey, valueFactory As Func(Of TKey, TArg, TValue), factoryArgument As TArg) As TValue
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'inserimento basato su setter, basato su interfaccia e basato su costruttore nei gestori e moduli, nelle istanze di Page e nei controlli utente dei progetti di applicazioni Web ASP.NET.
Usare l'inserimento basato su setter e basato sull'interfaccia nei handler e moduli, nelle istanze delle pagine e nei controlli utente di progetti di siti 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 HttpCookie oggetti, nonché ai FormsAuthentication cookie e System.Web.SessionState.
È possibile impostare SameSite per un HttpCookie oggetto come indicato di seguito:
var c = new HttpCookie("secureCookie", "same origin");
c.SameSite = SameSiteMode.Lax;
Dim c As 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 i cookie modificando il file di configurazione Web:
<system.web>
<authentication mode="Forms">
<forms cookieSameSite="Lax">
<!-- ... -->
</forms>
</authentication>
<sessionState cookieSameSite="Lax"></sessionState>
</system.web>
Rete
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 fornisce ora un'implementazione per queste proprietà. Le proprietà sono:
SQLClient
Support for Azure Active Directory Universal Authentication and Multifactor authentication
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 le stringhe di connessione SQLClient aggiungendo un nuovo valore, "Active Directory Interactive", per la parola chiave "Authentication" esistente per supportare l'autenticazione MFA e Azure l'autenticazione AD. Il nuovo metodo interattivo supporta utenti nativi e federati 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 SqlAuthenticationMethod.ActiveDirectoryPassword e SqlAuthenticationMethod.ActiveDirectoryIntegrated. Entrambi fanno parte del protocollo ADAL non interattivo, che non supporta l'autenticazione a più fattori. 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 nel connection string.
Per altre informazioni e un esempio, vedere "SQL -- Azure AD Universal and Multifactor Authentication Support" nel blog di .NET blog.
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 che può essere considerata parte 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:
SqlConnectionStringBuilder.EnclaveAttestationUrl, che specifica l'URI per Always Encrypted basato sull'enclave.
SqlColumnEncryptionEnclaveProvider, ovvero una classe astratta da cui derivano tutti i provider di enclave.
SqlEnclaveSession, che incapsula lo stato per una determinata sessione di enclave.
SqlEnclaveAttestationParameters, che fornisce i parametri di attestazione usati da SQL Server per ottenere informazioni necessarie per eseguire un particolare protocollo di attestazione.
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:
L'utente crea una connessione AlwaysEncrypted a SQL Server che supporta Always Encrypted basato sull'enclave. Il driver contatta il servizio di attestazione per assicurarsi che si stia connettendo all'enclave corretta.
Dopo l'attestazione dell'enclave, il driver stabilisce un canale sicuro con l'enclave sicuro ospitato in SQL Server.
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 il ResourceDictionaries creato da un URI di origine specificato. Questa funzionalità viene usata dagli assistenti di diagnostica, non dalle applicazioni di produzione. Un assistente di diagnostica, ad esempio la funzionalità "Modifica e continuazione" di Visual Studio, consente all'utente di modificare un ResourceDictionary con lo scopo che le modifiche vengono applicate 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"));
Dim dictionaries As IEnumerable(Of ResourceDictionary) = ResourceDictionaryDiagnostics.GetResourceDictionariesForSource(New Uri("pack://application:,,,/MyApp;component/MyRD.xaml"))
Il metodo restituisce un enumerabile vuoto a meno che non VisualDiagnostics sia abilitato e la ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO variabile di ambiente 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, ad esempio la funzionalità "Modifica e continuazione" di Visual Studio può voler estendere questa funzionalità 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 Resources proprietà fa riferimento al dizionario (direttamente o indirettamente tramite la ResourceDictionary.MergedDictionaries proprietà ). Tre nuovi metodi statici implementati nella classe
Questi metodi restituiscono un enumerabile vuoto a meno che non VisualDiagnostics sia abilitato e la ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO variabile di ambiente 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 esegue questa operazione 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 ResourceDictionaryDiagnostics.StaticResourceResolved evento:
public static event EventHandler<StaticResourceResolvedEventArgs> StaticResourceResolved;
Public Shared Event StaticResourceResolved As EventHandler(Of StaticResourceResolvedEventArgs)
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; }
}
Public Class StaticResourceResolvedEventArgs : Inherits EventArgs
Public ReadOnly Property TargetObject As Object
Public ReadOnly Property TargetProperty As Object
Public ReadOnly Property ResourceDictionary As ResourceDictionary
Public ReadOnly Property ResourceKey As Object
End Class
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 Forms, Windows Presentation Foundation (WPF) e strumenti di Visual Studio per Office (VSTO) possono essere distribuite usando ClickOnce. Se nel manifesto dell'applicazione viene trovata la voce seguente, 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 le applicazioni Windows Forms, la precedente soluzione alternativa all'impostazione della consapevolezza DPI nel file di configurazione dell'applicazione anziché nel file manifesto dell'applicazione non è più necessaria per il successo della distribuzione ClickOnce.
Novità di .NET Framework 4.7.1
.NET Framework 4.7.1 include nuove funzionalità nelle aree seguenti:
- classi base
- CLR (Common Language Runtime)
- Networking
- ASP.NET
Inoltre, un importante obiettivo di .NET Framework 4.7.1 è stato migliorato l'accessibilità, che consente a un'applicazione di offrire un'esperienza appropriata per gli utenti di Assistive Technology. Per informazioni sui miglioramenti dell'accessibilità in .NET Framework 4.7.1, vedere Novità dell'accessibilità in .NET Framework.
classi base
Support for .NET Standard 2.0
.NET Standard definisce un set di API che devono essere disponibili in ogni implementazione .NET che supporta tale versione dello standard. .NET Framework 4.7.1 supporta completamente .NET Standard 2.0 e aggiunge informazioni su 200 API definite in .NET Standard 2.0 e non sono presenti 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 altri file di supporto .NET Standard. Per altre informazioni, vedere "BCL - .NET Standard 2.0 Support" nel post di blog .NET Framework 4.7.1 Runtime and Compiler Features.
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 and Configuration Features.
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 runtime. 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 RuntimeFeature.IsSupported metodo 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 relativi tipi generici associati sono 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 altre informazioni, vedere "Compiler -- ValueTuple is Serializable" nel post di blog .NET Framework 4.7.1 Runtime and Compiler Features.
Supporto per i riferimenti di sola lettura
.NET Framework 4.7.1 aggiunge 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 "Compiler -- Support for ReadOnlyReferences" (Supporto per ReadOnlyReferences) nel post di blog .NET Framework 4.7.1 Runtime and Compiler Features. Per informazioni sui valori restituiti ref, vedere valori restituiti ref e ref locals e valori restituiti ref (Visual Basic).
CLR (Common Language Runtime)
miglioramenti delle prestazioni di Garbage Collection
Le modifiche apportate a Garbage Collection (GC) in .NET Framework 4.7.1 migliorano le prestazioni complessive, soprattutto per le allocazioni di heap oggetti di grandi dimensioni. In .NET Framework 4.7.1, i blocchi separati vengono usati per le allocazioni SOH (Object Heap) e LOH di piccole dimensioni, che consentono l'esecuzione di allocazioni LOH quando il processo di GC in background 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 altre informazioni, vedere la sezione "Runtime -- GC Performance Improvements" nel post di blog .NET Framework 4.7.1 Runtime and Compiler Features.
Rete
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.Sha384 e HashAlgorithm.Sha512. L'effettivo utilizzo di questo valore dipende da MSMQ, poiché l'istanza stessa non esegue l'hashing Message , 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 and Configuration features.
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 ogni gestore eventi come passaggio di esecuzione. Nelle versioni di ASP.NET fino a .NET Framework 4.7, ASP.NET non può propagare il contesto di esecuzione a causa della commutazione tra thread nativi e gestiti. Al contrario, ASP.NET trasmette 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 "ASP.NET Execution Step Feature" nel post di blog .NET Framework 4.7.1 ASP.NET and Configuration Features.
Analisi di HttpCookie in ASP.NET
.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 sintattica di ASP.NET HttpCookie" nel post di blog .NET Framework 4.7.1 ASP.NET and Configuration Features.
opzioni hash SHA-2 per le credenziali di autenticazione dei form di ASP.NET
In .NET Framework 4.7 e versioni precedenti, ASP.NET consentiva agli sviluppatori di archiviare le credenziali utente con password con algoritmo di hashing nei file di configurazione usando l'MD5 o l'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 ci si connette a Azure SQL, Managed Identities for Azure resources è il metodo di autenticazione consigliato.
Novità di .NET Framework 4.7
.NET Framework 4.7 include nuove funzionalità nelle aree seguenti:
- classi base
- Networking
- ASP.NET
- Windows Communication Foundation (WCF)
- Windows Forms
- Windows Presentation Foundation (WPF)
Per un elenco delle nuove API aggiunte a .NET Framework 4.7, vedere .NET Framework 4.7 Api Changes on GitHub. Per un elenco dei miglioramenti delle funzionalità e delle correzioni di bug in .NET Framework 4.7, vedere .NET Framework 4.7 List of Changes on GitHub. Per altre informazioni, vedere Announcing .NET Framework 4.7 nel blog di .NET.
classi base
.NET Framework 4.7 migliora la serializzazione in base al DataContractJsonSerializer:
Funzionalità avanzata con* Elliptic Curve Cryptography (ECC)
In .NET Framework 4.7, ImportParameters(ECParameters) metodi sono stati aggiunti alle classi ECDsa e ECDiffieHellman per consentire a un oggetto di rappresentare una chiave già stabilita. È stato aggiunto anche un ExportParameters(Boolean) metodo per esportare la chiave usando parametri di curva espliciti.
.NET Framework 4.7 aggiunge anche il supporto per le curve aggiuntive (incluso il gruppo di curve Brainpool) e ha aggiunto definizioni predefinite per facilitare la creazione tramite i nuovi metodi factory Create e Create.
È possibile visualizzare un esempio dei miglioramenti della crittografia di .NET Framework 4.7 in 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.
Rete
.NET Framework 4.7 aggiunge la funzionalità correlata alla rete seguente:
Supporto predefinito del sistema operativo per i protocolli TLS*
Lo stack TLS, utilizzato da System.Net.Security.SslStream e componenti dello stack come HTTP, FTP e SMTP, consente agli sviluppatori di utilizzare 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 il monitoraggio della memorizzazione nella cache degli oggetti in memoria e 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 monitoraggio della memoria predefinito in ASP.NET notifica alle applicazioni quando sono in esecuzione vicino al limite di byte privati configurato per il processo o quando il computer è basso sul totale della RAM fisica 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 ApplicationMonitors.MemoryMonitor proprietà .
Reazioni al limite di memoria. Per impostazione predefinita, ASP.NET tenta di tagliare la cache degli oggetti e chiamare periodicamente GC.Collect quando il limite del processo di byte privato è 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
IObserverle implementazioni 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
SharedConnectionListenere DuplexChannelBinder. - Maggiore affidabilità delle operazioni di serializzazione quando si chiama il FormatterServices.GetSerializableMembers(Type) metodo .
- Miglioramento dell'affidabilità quando si rimuove un cameriere chiamando il metodo
ChannelSynchronizer.RemoveWaiter.
Windows Forms
In .NET Framework 4.7, Windows Forms migliora il supporto per i monitor dpi elevati.
supporto dpi elevato
A partire dalle applicazioni destinate al .NET Framework 4.7, il .NET Framework include il supporto per DPI elevati e DPI dinamici nelle 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 dpi elevato è una funzionalità di consenso esplicito configurata definendo un <System. Windows. Forms.ConfigurationSection> sezione del file di configurazione dell'applicazione. Per altre 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 su messaggi di Windows WM_POINTER
Ora hai l'opzione di usare uno stack touch/stilo basato su messaggi WM_POINTER invece della piattaforma Windows WISP (Ink Services Platform). 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 del pacchetto di documenti Windows Print Document Package anziché l'API di stampa deprecata XPS Print API. Per l'impatto di questa modifica sulla compatibilità delle applicazioni, vedere la sezione 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 .NET Framework 4.6.2 Api Changes on GitHub. Per un elenco dei miglioramenti delle funzionalità e delle correzioni di bug in .NET Framework 4.6.2, vedere .NET Framework 4.6.2 List of Changes on GitHub. Per altre informazioni, vedere Announcing .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 dei dati
I validator di annotazione dati consentono di eseguire la convalida aggiungendo uno o più attributi a una proprietà di classe. L'elemento dell'attributo ValidationAttribute.ErrorMessage 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:
L'oggetto ValidationAttribute.ErrorMessage viene fornito nell'attributo di convalida.
Il file di risorse viene archiviato nella cartella App_LocalResources.
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.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; }
}
Public Class RatingInfo
<Required(ErrorMessage = "The rating must be between 1 and 10.")>
<Display(Name = "Your Rating")>
Public Property Rating As Integer = 1
End Class
È 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 App.LocalResources cartella . 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 per archiviare la IStringLocalizerProvider 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 dello stato sessione, consentendo così alle app di ASP.NET di ottenere i vantaggi di scalabilità di asincrona. Per supportare operazioni asincrone con provider dell'archivio stati della 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 sessione e i provider di archivio sessioni asincroni. L'interfaccia è definita come segue:
public interface ISessionStateModule : IHttpModule {
void ReleaseSessionState(HttpContext context);
Task ReleaseSessionStateAsync(HttpContext context);
}
Public Interface ISessionStateModule : Inherits IHttpModule
Sub ReleaseSessionState(context As HttpContext)
Function ReleaseSessionStateAsync(context As HttpContext) As Task
End Interface
Inoltre, la SessionStateUtility classe include due nuovi metodi, IsSessionStateReadOnly e IsSessionStateRequired, che possono essere usati per supportare le operazioni asincrone.
Supporto asincrono per i provider del cache di output
A partire da .NET Framework 4.6.2, i metodi che restituiscono attività possono essere usati con i provider di cache di output per offrire i vantaggi di scalabilità dell'asincronia. 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:
La System.Web.Caching.OutputCacheProviderAsync classe , che eredita da System.Web.Caching.OutputCacheProvider e consente agli sviluppatori di implementare un provider di cache di output asincrono.
Classe OutputCacheUtility , che fornisce metodi helper per la configurazione della cache di output.
18 nuovi metodi nella System.Web.HttpCachePolicy classe . Sono inclusi GetCacheability, GetCacheExtensions, GetETag, GetETagFromFileDependencies, GetMaxAge, GetMaxAge, GetNoStore, GetNoTransforms, GetOmitVaryStar, GetProxyMaxAge, GetRevalidation, GetUtcLastModified, GetVaryByCustom, HasSlidingExpiration e IsValidUntilExpires.
2 nuovi metodi nella System.Web.HttpCacheVaryByContentEncodings classe : GetContentEncodings e SetContentEncodings.
2 nuovi metodi nella System.Web.HttpCacheVaryByHeaders classe : GetHeaders e SetHeaders.
2 nuovi metodi nella System.Web.HttpCacheVaryByParams classe : GetParams e SetParams.
Nella classe System.Web.Caching.AggregateCacheDependency il metodo GetFileDependencies.
Nel CacheDependency, il metodo GetFileDependencies.
categorie di caratteri
I caratteri in .NET Framework 4.6.2 vengono classificati in base al Unicode Standard, 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 CharUnicodeInfo classe e ai tipi e ai metodi che si basano su di esso. Sono incluse la classe
Per le modifiche apportate alle categorie di caratteri da Unicode 6.0 a Unicode 7.0, vedere Lo standard Unicode versione 7.0.0 nel sito Web del Consorzio Unicode. 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 System.Security.Cryptography.DSACng classe.
In linea con le modifiche recenti 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 utilizzare questa funzionalità senza necessità di conversione. È possibile chiamare il DSACertificateExtensions.GetDSAPrivateKey metodo di estensione 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);
}
}
Public Shared Function SignDataDsaSha384(data As Byte(), cert As X509Certificate2) As Byte()
Using DSA As DSA = cert.GetDSAPrivateKey()
Return DSA.SignData(data, HashAlgorithmName.SHA384)
End Using
End Function
È anche possibile chiamare il DSACertificateExtensions.GetDSAPublicKey metodo di estensione 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);
}
}
Public Shared Function VerifyDataDsaSha384(data As Byte(), signature As Byte(), cert As X509Certificate2) As Boolean
Using dsa As DSA = cert.GetDSAPublicKey()
Return dsa.VerifyData(data, signature, HashAlgorithmName.SHA384)
End Using
End Function
Maggiore chiarezza per gli input nelle routine di derivazione della chiave ECDiffieHellman
.NET Framework 3.5 ha aggiunto il supporto per l'accordo di chiave Diffie-Hellman con curva ellittica utilizzando tre diverse routine di Funzione di Derivazione della Chiave (KDF). 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 della chiave attraverso 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 Windows libreria di crittografia (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.
Il supporto della crittografia simmetrica con chiave persistente è disponibile 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);
}
}
}
Public Shared Function EncryptDataWithPersistedKey(data As Byte(), iv As Byte()) As Byte()
Using Aes As Aes = New AesCng("AesDemoKey", CngProvider.MicrosoftSoftwareKeyStorageProvider)
Aes.IV = iv
' Using the zero-argument overload Is required to make use of the persisted key
Using encryptor As ICryptoTransform = Aes.CreateEncryptor()
If Not encryptor.CanTransformMultipleBlocks Then
Throw New InvalidOperationException("This is a sample, this case wasn't handled...")
End If
Return encryptor.TransformFinalBlock(data, 0, data.Length)
End Using
End Using
End Function
supporto per SignedXml per l'hashing SHA-2
.NET Framework 4.6.2 aggiunge supporto alla classe SignedXml per i metodi di firma RSA-SHA256, RSA-SHA384 e RSA-SHA512 PKCS#1 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 personalizzato SignatureDescription 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 CryptoConfig registrazione non è più necessaria.
SqlClient
.NET Framework Data Provider per SQL Server (System.Data.SqlClient) include le nuove funzionalità seguenti in .NET Framework 4.6.2:
Pooling di connessioni e timeout con Azure SQL Database
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 ulteriori informazioni, consultare Pool di connessioni SQL Server (ADO.NET).
Questo comportamento non è consigliabile quando ci si connette a Azure SQL Database, poiché i tentativi di connessione possono non riuscire con errori temporanei che vengono in genere ripristinati rapidamente. Per ottimizzare l'esperienza di ripetizione dei tentativi di connessione, il comportamento del periodo di blocco del pool di connessioni viene rimosso quando le connessioni a Azure SQL Database hanno esito negativo.
L'aggiunta della nuova PoolBlockingPeriod parola chiave consente di selezionare il periodo di blocco più adatto per l'app. I valori includono:
Il periodo di blocco del pool di connessioni per un'applicazione che si connette a un Azure SQL Database è disabilitato e il periodo di blocco del pool di connessioni per un'applicazione che si connette a qualsiasi altra istanza di SQL Server è abilitata. Questo è il valore predefinito. Se il nome dell'endpoint server termina con uno dei seguenti, vengono considerati Azure SQL Database:
.database.windows.net
.database.chinacloudapi.cn
.database.usgovcloudapi.net
.database.cloudapi.de
Il periodo di blocco del pool di connessioni è sempre abilitato.
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 SqlConnection.ColumnEncryptionQueryMetadataCacheEnabled proprietà 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 usando la libreria di crittografia 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 .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 al file <runtime> della sezione 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);
Const DisableCngCertificates As String = "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 DataContractJsonSerializer classe 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 DataContractJsonSerializer oggetto usa il TimeZoneInfo tipo anziché il TimeZone tipo per deserializzare i dati di data e ora. TimeZoneInfo supporta più regole di regolazione, che consente di lavorare con i dati cronologici del fuso orario; TimeZone Non.
Per altre informazioni sulla struttura e sulle regolazioni del TimeZoneInfo 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.
Proprietà TcpTransportSecurity.SslProtocols
Sezione <sslStreamSecurity> della sezione <customBinding>
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 CollectionView oggetto 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 GroupDescription.SortDescriptions proprietà e GroupDescription.CustomSort descrivono come ordinare la raccolta di gruppi prodotti dall'oggetto GroupDescription . Questo è analogo al modo in cui le proprietà denominate ListCollectionView in modo identico descrivono come ordinare gli elementi di dati.
Per i casi più comuni, è possibile usare due nuove proprietà statiche della PropertyGroupDescription classe 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 della tastiera virtuale consente il tracciamento dello stato attivo nelle applicazioni WPF richiamando e chiudendo automaticamente la tastiera virtuale in Windows 10 quando l'input tattile viene ricevuto da un controllo che può accettare input testuale.
Nelle versioni precedenti di .NET Framework, le applicazioni WPF non possono abilitare il rilevamento dello stato attivo senza disabilitare il supporto ai gesti penna/tocco di WPF. Di conseguenza, le applicazioni WPF devono scegliere tra il supporto completo per il tocco 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 in .NET Framework 4.6.2 consente la consapevolezza per monitor. Consultare gli esempi e la guida per gli sviluppatori su GitHub per ulteriori informazioni su come abilitare la propria app WPF a diventare consapevole del DPI per monitor.
Nelle versioni precedenti di .NET Framework, le app WPF sono compatibili con 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. Il Progettista del Workflow Rehosted è una funzionalità chiave di Windows Workflow Foundation (WF) che consente al Progettista del Workflow di trovarsi in un'applicazione all'esterno di Visual Studio, ad esempio in WPF. Windows Workflow Foundation offre la possibilità di supportare espressioni C# e IntelliSense in Progettazione flussi di lavoro rehosted. Per altre informazioni, vedere 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 di Windows Platform FIPS".
Miglioramenti del flusso di lavoro quando si utilizza l'aggiornamento dinamico con il 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 prima di .NET Framework 4.6.2, il caricamento di un file XAML in Visual Studio per un flusso di lavoro salvato dopo aver chiamato 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 Forms e WPF in app UWP
Windows ora offre funzionalità per portare le app desktop Windows esistenti, incluse le app WPF e Windows Forms, all'Universal Windows Platform (UWP). 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 piena fiducia può essere rimosso e la nuova app UWP può essere resa disponibile a tutti i dispositivi Windows 10.
miglioramenti al debug
L'API di debug unmanaged debugging è 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'interfaccia ICorDebugCode4, ICorDebugVariableHome e ICorDebugVariableHomeEnum, che espongono le posizioni native delle variabili gestite. Ciò consente ai debugger di eseguire alcune analisi del flusso di codice quando si verifica un NullReferenceException oggetto e di lavorare all'indietro per determinare la variabile gestita che corrisponde alla posizione nativa che era
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:
.NET Framework API diff (in GitHub)
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);
}
}
Imports System.Security.Cryptography
Imports System.Security.Cryptography.X509Certificates
Public Class Net461Code
Public Shared Function SignECDsaSha512(data As Byte(), cert As X509Certificate2) As Byte()
Using privateKey As ECDsa = cert.GetECDsaPrivateKey()
Return privateKey.SignData(data, HashAlgorithmName.SHA512)
End Using
End Function
Public Shared Function SignECDsaSha512(data As Byte, privateKey As ECDsa) As Byte()
Return privateKey.SignData(data, HashAlgorithmName.SHA512)
End Function
End Class
Questo offre un chiaro 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);
}
}
Imports System.Security.Cryptography
Imports System.Security.Cryptography.X509Certificates
Public Class Net46Code
Public Shared Function SignECDsaSha512(data As Byte(), cert As X509Certificate2) As Byte()
' 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...")
End Function
Public Shared Function SignECDsaSha512(data As Byte(), privateKey As ECDsa) As Byte()
' This way works, but SignData probably better matches what you want.
Using hasher As SHA512 = SHA512.Create()
Dim signature1 As Byte() = privateKey.SignHash(hasher.ComputeHash(data))
End Using
' This might not be the ECDsa you got!
Dim ecDsaCng As ECDsaCng = CType(privateKey, ECDsaCng)
ecDsaCng.HashAlgorithm = CngAlgorithm.Sha512
Return ecDsaCng.SignData(data)
End Function
End Class
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 il connection string per includere "MultisubnetFailover=true" per indicare che si stava connettendo 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 è più necessario impostare MultiSubnetFailover 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 nella generazione 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 altre lingue di controllo ortografico. Non sono state apportate modifiche alle funzionalità delle versioni di Windows prima di 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 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 per WPF nelle applicazioni devono continuare a usare i file con estensione lex.
Esempi
Sono disponibili diversi esempi di WPF nel repository Microsoft/WPF-Samples GitHub. Aiutaci a migliorare gli esempi inviando una richiesta pull o aprendo un problema 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 on 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.
profilo
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 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
ICorProfilerAPI 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 nuoviAssemblyRefrecord ,TypeRef,TypeSpecMemberRefMemberSpece .UserStringQuesta modifica rende possibile una gamma molto più ampia di strumentazione on-the-fly.
Generatore di immagini native (NGEN) PDBs
La tracciatura degli eventi cross-macchina consente ai clienti di profilare un programma sulla Macchina A e di esaminare i dati di profilatura con la mappatura delle righe di codice sorgente sulla Macchina B. Usando le versioni precedenti di .NET Framework, l'utente copierebbe tutti i moduli e le immagini native dalla macchina profilata alla macchina di analisi che contiene il PDB IL per creare la mappatura da codice sorgente a codice 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 macchine, tutto ciò che è necessario è copiare il PDB dell'immagine nativa generato dalla macchina A nella macchina B e utilizzare le API di accesso all'interfaccia di Debug per leggere il mapping da sorgente a IL del PDB e il mapping da IL a nativo dell'immagine PDB. 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 il .NET Framework 4.6 e .NET Core. Alcune nuove funzionalità si applicano sia a che ad altre funzionalità sono specifiche di .NET Framework 4.6 o .NET Core.
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 creare app ASP.NET Core tramite strumenti in Visual Studio 2015 o versione successiva. Le applicazioni esistenti funzioneranno sul nuovo framework di .NET. 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.
ASP.NET Aggiornamenti
API basata su compiti per lo svuotamento asincrono della risposta
ASP.NET offre ora una semplice API basata su attività per lo svuotamento asincrono delle risposte, HttpResponse.FlushAsync, che consente di scaricare le risposte in modo asincrono usando il supporto del linguaggio
async/await.l'associazione di modelli supporta i metodi di restituzione delle attività
In .NET Framework 4.5, ASP.NET aggiunto la funzionalità di associazione di modelli che abilitava un approccio estendibile incentrato sul codice per le operazioni sui dati basate su CRUD nelle pagine Web Form 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 hanno come target .NET Framework 4.6, per impostazione predefinita è
true. Nelle app in esecuzione in .NET Framework 4.6 destinate a una versione precedente di .NET Framework, èfalseper impostazione predefinita. Può essere abilitata impostando l'impostazione di configurazione sutrue.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. È necessario essere in esecuzione in Windows 10 per usare HTTP/2 con ASP.NET.
HTTP/2 è supportato e attivato per impostazione predefinita per le app Windows 10 Universal Windows Platform (UWP) che usano l'API System.Net.Http.HttpClient.
Per consentire l'uso della funzionalità 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
Mentre 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 collaborano 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 di token verrà implementato in Windows 10 come funzionalità del browser. ASP.NET app parteciperanno al protocollo, in modo che i token di autenticazione vengano convalidati per essere 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 hash di stringa randomizzato. Tuttavia, non è stato supportato da ASP.NET a causa di alcune funzionalità di ASP.NET dipende 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
aspnet:UseRandomizedStringHashAlgorithmdi configurazione.<appSettings> <add key="aspnet:UseRandomizedStringHashAlgorithm" value="true|false" /> </appSettings>
ADO.NET
ADO .NET ora supporta 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 (Database Engine) 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 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.CurrentCulturee la cultura del thread dell'interfaccia utente corrente definita dalla proprietàThread.CurrentThread.CurrentUICulturecambiano.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 Windows CNG. Le versioni precedenti di .NET Framework si basano interamente su una versione earlier delle API di crittografia Windows come base per l'implementazione di 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 Windows:
Set di metodi di estensione per certificati
System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(System.Security.Cryptography.X509Certificates.X509Certificate2)X509 eSystem.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 tramite 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);Dim rsa As RSACryptoServiceProvider = CType(cert.PrivateKey, RSACryptoServiceProvider) Dim oaepEncrypted() As Byte = rsa.Encrypt(data, True) Dim pkcs1Encrypted() As Byte = rsa.Encrypt(data, False)Il codice che usa le nuove API di crittografia in .NET Framework 4.6 può essere riscritto come segue 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);Dim rsa As RSA = cert.GetRSAPrivateKey() If rsa Is Nothing Then Throw New InvalidOperationException("An RSA certificate was expected") End If Dim oaepEncrypted() As Byte = rsa.Encrypt(data, RSAEncryptionPadding.OaepSHA1) Dim pkcs1Encrypted() As Byte = rsa.Encrypt(data, RSAEncryptionPadding.Pkcs1)
Supporto per la conversione di date e orari da o verso l'ora Unix
Alla struttura sono stati aggiunti i nuovi metodi seguenti per supportare la DateTimeOffset 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 Boolean valore) definita da una libreria dipendente. L'opzione è sempre implicitamente
false. Impostando l'interruttore sutrueesso viene abilitato. L'impostazione esplicita del commutatore sufalsegenera il nuovo comportamento.AppContext.SetSwitch("Switch.AmazingLib.ThrowOnException", true);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 }If Not AppContext.TryGetSwitch("Switch.AmazingLib.ThrowOnException", shouldThrow) Then ' 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. End If ' The library can use the value of shouldThrow to throw exceptions or not. If shouldThrow Then ' old code Else ' new code End IfÈ 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, Task e Task<TResult> ereditano la cultura e la cultura 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 System.Threading.AsyncLocal<T> classe consente di rappresentare i dati di ambiente locali per un determinato flusso di controllo asincrono, ad esempio un
asyncmetodo. 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 AsyncLocal<T>.Value proprietà è 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 ora supporta la comunicazione asincrona con il suo nuovo ConnectAsync. metodo.
EventSource supporta ora la scrittura nel registro eventi
È ora possibile usare la EventSource classe 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 a versioni precedenti del framework ma sono in esecuzione in .NET Framework 4.6 possono acconsentire esplicitamente al nuovo comportamento aggiungendo la riga seguente alla sezione <runtime> sezione 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 con DPI multipli) sono ora completamente renderizzate senza aree nere. È possibile rifiutare esplicitamente questo comportamento aggiungendo la riga seguente alla
<appSettings>sezione del file di 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
Le segnalazioni dei clienti su Connect in cui il tocco produce comportamenti imprevedibili sono state affrontate nel .NET Framework 4.6. La soglia di doppio tocco per le applicazioni Windows Store e le applicazioni WPF è ora uguale in Windows 8.1 e versioni successive.
Supporto per finestre figlio trasparenti
WPF in .NET Framework 4.6 supporta finestre figlio 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 HwndSourceParameters.UsesPerPixelTransparency proprietà 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 SslProtocols proprietà 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 tramite 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à del Message.Properties 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 quanto segue
appSettingsutrue:<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
appSettingssezione 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
appSettingssezione del file app.config:<add key="Transactions:IncludeDistributedTransactionIdInExceptionMessage" value="true"/>Il valore predefinito è
false.Networking
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 di .NET di sfruttare il nuovo comportamento. Nelle versioni precedenti di Windows c'era 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 durante il 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:
Valore di enumerazione System.Net.Sockets.SocketOptionName.
Proprietà ServicePointManager.ReusePort.
Per impostazione predefinita, la ServicePointManager.ReusePort proprietà è
falsea meno che ilHWRPortReuseOnSocketBindvalore della chiave delHKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319Registro di sistema non sia impostato su 0x1. Per abilitare il riutilizzo delle porte locali nelle connessioni HTTP, impostare la ServicePointManager.ReusePort proprietà sutrue. In questo modo, tutte le connessioni socket TCP in uscita da HttpClient e HttpWebRequest utilizzano una nuova opzione socket di Windows 10, SO_REUSE_UNICASTPORT, che consente di riutilizzare la porta locale.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 Uri classe per supportare meglio i nomi di dominio internazionali e PunyCode.
Ridimensionamento nei controlli di Windows Forms.
Questa funzionalità è stata espansa in .NET Framework 4.6 per includere il
, , , e tipi / e il rettangolo specificato dalla proprietà /> . Si tratta di una funzionalità di consenso esplicito. Per abilitarla, impostare l'elemento
EnableWindowsFormsHighDpiAutoResizingsutruenel 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 fornisce supporto limitato per le codifiche della tabella codici. È possibile aggiungere il supporto per le codifiche della tabella codici disponibili in .NET Framework, ma non supportato in .NET Core registrando le codifiche della tabella codici con il metodo Encoding.RegisterProvider. Per altre informazioni, vedere System.Text.CodePagesEncodingProvider.
.NET Native
Universal Windows Platform (UWP) app scritte in C# o Visual Basic possono sfruttare una nuova tecnologia che compila le app in codice nativo invece di IL. Questa tecnologia produce app con tempi di avvio e esecuzione più veloci. Per altre informazioni, vedere Compiling Apps with .NET Native( Per una panoramica di .NET Native che esamina le differenze tra compilazione JIT e NGEN e ciò che significa per il codice, vedere .NET Native and 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 .NET app native, sono state aggiunte nuove interfacce ed enumerazioni all'API di debug non gestita. Per altre informazioni, vedere Debug (Informazioni di riferimento sulle API non gestite).
pacchetti Open-source .NET Framework
.NET pacchetti Core, ad esempio le raccolte non modificabili, le API SIMD e le API di rete come 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 altre informazioni e come contribuire a questi pacchetti, vedere Introduzione a .NET, .NET Home Page in 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 invece degli eventi PreSendRequestHeaders e PreSendRequestContent; sono più efficienti e affidabili.
Il HostingEnvironment.QueueBackgroundWorkItem metodo 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 HttpResponse.HeadersWritten proprietà e HttpResponseBase.HeadersWritten restituiscono valori booleani che indicano se le intestazioni della 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 dei controlli di 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
EnableWindowsFormsHighDpiAutoResizingsutruenel 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 EnlistPromotableSinglePhase metodo (e quindi l'implementazione dell'interfaccia IPromotableSinglePhaseNotification ) può usare il nuovo Transaction.PromoteAndEnlistDurable metodo per richiedere quanto segue:
Alzare di livello la transazione a una transazione Microsoft Distributed Transaction Coordinator (MSDTC).
Sostituire IPromotableSinglePhaseNotification con un ISinglePhaseNotification, che è un arruolamento durevole che supporta un commit singolo.
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 IPromotableSinglePhaseNotification
Promoteimplementato dalla partecipazione promuovibile.Miglioramenti della profilazione. Le nuove API di profilatura non gestite seguenti offrono una profilatura più affidabile:
- COR_PRF_ASSEMBLY_REFERENCE_INFO Struttura
- COR_PRF_HIGH_MONITOR di enumerazione
- Metodo GetAssemblyReferences
- Metodo GetEventMask2
- Metodo SetEventMask2
- Metodo AddAssemblyReference
Le precedenti implementazioni di
ICorProfilersupportavano 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 esistentiICorProfiler.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 la tracciatura delle attività basata su Event Tracing for Windows (ETW) fuori processo per un'area più ampia. 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)<System.Security.Permissions.PermissionSetAttribute(System.Security.Permissions.SecurityAction.LinkDemand, Name:="FullTrust")> public Function PromoteAndEnlistDurable(resourceManagerIdentifier As Guid, promotableNotification As IPromotableSinglePhaseNotification, enlistmentNotification As ISinglePhaseNotification, enlistmentOptions As EnlistmentOptions) As EnlistmentIl metodo può essere usato da un arruolamento che è stato creato in precedenza da Transaction.EnlistPromotableSinglePhase in risposta al metodo ITransactionPromoter.Promote. Chiede a
System.Transactionsdi 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 daSystem.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 Windows Runtime API nelle librerie portabili destinate a Windows 8.1, Windows Phone 8.1 e Windows Phone Silverlight 8.1.
Puoi includere XAML (tipi di Windows.UI.XAML) nelle librerie portabili quando si mira a 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.
È possibile creare un componente Windows Runtime portabile (file con estensione winmd) da usare nelle app dello Store destinate a Windows 8.1 e Windows Phone 8.1.
È possibile reindirizzare una libreria di classi Windows Store o Windows Phone Store come una Libreria di Classi Portatile.
Per altre informazioni su queste modifiche, vedere libreria di classi portabile.
Il set di contenuto di .NET Framework include ora la documentazione per .NET Native, una tecnologia di precompilazione per la creazione e la distribuzione di app Windows. .NET Native compila le app direttamente nel codice nativo, anziché nel linguaggio intermedio (IL), per ottenere prestazioni migliori. Per informazioni dettagliate, vedere Compiling Apps with .NET Native.For details, see Compiling Apps with .NET Native.
L'origine di riferimento .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 e scorrere le origini (incluse patch e aggiornamenti) durante il debug. Per altre informazioni, vedere la voce di blog Un nuovo look per .NET Reference Source.
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 WriteEventWithRelatedActivityId metodi e WriteEventWithRelatedActivityIdCore nella EventSource classe .
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 in 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 .NET Framework 4.5.1 e il post di blog ASP.NET app suspend.
I miglioramenti apportati alle Windows Forms includono:
Ridimensionamento dei 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 Forms seguenti:
- PropertyGrid
- TreeView
- Alcuni aspetti della DataGridView (vedere nuove funzionalità nella versione 4.5.2 per controlli aggiuntivi supportati)
Per abilitare questa funzionalità, aggiungere un nuovo
<appSettings>elemento al file di configurazione (app.config) e impostare l'elementoEnableWindowsFormsHighDpiAutoResizingsutrue:<appSettings> <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" /> </appSettings>
I miglioramenti apportati al debug delle app di .NET Framework in Visual Studio 2013 includono:
Restituisce valori nel debugger 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 delle app asincrone in Visual Studio 2013, lo stack di chiamate nasconde il codice di infrastruttura fornito dai compilatori per supportare la programmazione asincrona e collega anche i frame padre logici, permettendo di 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. Per informazioni su questa funzionalità, vedere la sezione "Debug con riconoscimento asincrono" dell'annuncio .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 oltre i confini linguistici. È possibile leggere le informazioni su questa funzionalità nella sezione "sviluppo di app dello Store Windows" dell'annuncio .NET Framework 4.5.1.
A partire da Visual Studio 2013, puoi usare Managed Profile Guided Optimization Tool (Mpgo.exe) per ottimizzare le app dello Store Windows 8.x e le app desktop.
Per le nuove funzionalità di ASP.NET 4.5.1, vedere ASP.NET e Strumenti Web per Visual Studio versione 2013.
Novità di .NET Framework 4.5
classi base
Possibilità di ridurre i riavvii del sistema rilevando e chiudendo .NET Framework 4 applicazioni durante la distribuzione. Consulta 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 l'operazione di 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 Regex.MatchTimeout proprietà .
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 in Windows 8.
Delegazione del confronto tra stringhe al sistema operativo, che implementa Unicode 6.0, quando .NET Framework viene usato su Windows 8. In caso di esecuzione su altre piattaforme, il framework di .NET include i propri dati di confronto di stringhe, che implementa Unicode 5.x. Vedere la String classe e la sezione Osservazioni della SortVersion classe .
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. Vedi Reflection nel .NET Framework per app di 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.
Un subset di MEF che puoi usare quando crei app Windows 8.x Store. Questo subset è disponibile come pacchetto scaricabile dalla galleria NuGet. Per installare il pacchetto, aprire il progetto in Visual Studio, scegliere Gestisci pacchetti NuGet dal menu Project e cercare 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 .NET Framework 4.5 generatore di file di risorse (Resgen.exe) consente di creare un file con estensione resw da usare nelle app Windows 8.x Store da un file con estensione resources incorporato in un assembly di .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, è possibile 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 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:
Note sulla versione ASP.NET e Strumenti Web per Visual Studio 2013
Rete
.NET Framework 4.5 fornisce 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 esistenti HttpListener e correlate. Per altre informazioni, vedere il nuovo System.Net.WebSockets spazio dei nomi e la HttpListener classe .
Inoltre, .NET Framework 4.5 include i miglioramenti di rete seguenti:
Supporto URI conforme a RFC. Per altre informazioni, vedere Uri e le classi correlate.
Supporto per il parsing degli IDN (Internationalized Domain Name). Per altre informazioni, vedere Uri e le 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, consultare lo spazio dei nomi System.Net.NetworkInformation.
Supporto socket a doppia modalità. Per altre informazioni, vedere le Socket classi 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.
INotifyDataErrorInfo Nuova interfaccia, che supporta la convalida sincrona e asincrona dei dati.
Nuove funzionalità per le VirtualizingPanel classi 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.
Possibilità 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 XmlDictionaryReaderQuotas classe per ridurre la probabilità che sia necessario configurare manualmente le quote per i lettori di dizionario XML.
Convalida dei file di configurazione WCF 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 usando Internet Information Services (IIS).
Possibilità di generare metadati in un singolo documento WSDL aggiungendo
?singleWSDLall'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à di 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à avanzate di ricerca del flusso di lavoro in Visual Studio, tra cui Quick Find e Find in Files.
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 Visual Basic e i progetti del 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 di flusso di lavoro C# che usano espressioni C#.
Miglioramenti del versionamento:
WorkflowIdentity Nuova classe, 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à di Windows Workflow Foundation.
.NET per le app dello Store Windows 8.x
Le app del Windows Store 8.x sono progettate per specifiche form factor e sfruttano la potenza del sistema operativo Windows. È disponibile un subset di .NET Framework 4.5 o 4.5.1 per la compilazione di app Windows 8.x Store per Windows tramite C# o Visual Basic. Questo sottoinsieme viene chiamato .NET per le app dello Store Windows 8.x ed è descritto in un overview.
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 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.