Modifiche di ridestinazione per la migrazione a .NET Framework 4.6.x

Questo articolo elenca i problemi di compatibilità delle applicazioni introdotti in .NET Framework 4.6, 4.6.1 e 4.6.2.

.NET Framework 4.6

ASP.NET

HtmlTextWriter non esegue correttamente il rendering dell'elemento <br/>

Dettagli

A partire da .NET Framework 4.6, la chiamata di RenderBeginTag(String) e RenderEndTag() con un elemento <BR /> inserirà correttamente solo un <BR /> (invece di due)

Suggerimento

Se un'app dipende dal tag <BR /> aggiuntivo, il metodo RenderBeginTag(String) deve essere chiamato una seconda volta. Si noti che questa modifica di comportamento influisce solo sulle app destinate a .NET Framework 4.6 o versioni successive, quindi è possibile in alternativa selezionare una versione precedente di .NET Framework come destinazione per ottenere il comportamento precedente.

Nome	valore
Scope	Edge
Versione	4.6
Type	Ridestinazione

API interessate

• HtmlTextWriter.RenderBeginTag(String)
• HtmlTextWriter.RenderBeginTag(HtmlTextWriterTag)

ClickOnce

Possibili errori in Windows 2003 per le app pubblicate con ClickOnce che usano un certificato per la firma del codice SHA-256

Dettagli

Il file eseguibile è firmato con SHA256. In precedenza, veniva firmato con SHA1 indipendentemente dal fatto che il certificato di firma del codice fosse SHA-1 o SHA-256. Si applica a:

• Tutte le applicazioni compilate con Visual Studio 2012 o versioni successive.
• Applicazioni compilate con Visual Studio 2010 o versioni precedenti su sistemi in cui è presente .NET Framework 4.5. Se inoltre è presente .NET Framework 4.5 o versione successiva, il manifesto ClickOnce viene firmato anche con SHA-256 per i certificati SHA-256 indipendentemente dalla versione di .NET Framework per cui è stato compilato.

Suggerimento

La modifica della firma del file eseguibile di ClickOnce interessa solo i sistemi Windows Server 2003, in cui è richiesta l'installazione di quanto indicato nell'articolo 938397 della Knowledge Base . La modifica relativa alla firma del manifesto con SHA-256 anche quando un'app è destinata a .NET Framework 4.0 o a versioni precedenti introduce una dipendenza del runtime da .NET Framework 4.5 o da una versione successiva.

Nome	valore
Scope	Edge
Versione	4.5
Type	Ridestinazione

ClickOnce supporta SHA-256 per le app destinate alla versione 4.0

Dettagli

In precedenza, un'app ClickOnce con certificato firmato con SHA-256 avrebbe richiesto la presenza di .NET Framework 4.5 o versioni successive, anche se l'app era destinata alla versione 4.0. È ora possibile eseguire le app ClickOnce destinate a .NET Framework 4.0 in .NET Framework 4.0, anche se firmate con SHA-256.

Suggerimento

Questa modifica rimuove tale dipendenza e consente di usare i certificati SHA-256 per firmare le app ClickOnce destinate a .NET Framework 4 e versioni precedenti.

Nome	valore
Scope	Secondarie
Versione	4.6
Type	Ridestinazione

Memoria centrale

CurrentCulture e CurrentUICulture vengono propagate tra le attività

Dettagli

A partire da .NET Framework 4.6, le proprietà System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture sono archiviate in System.Threading.ExecutionContext del thread, che viene propagato tra le operazioni asincrone. Ciò significa che le modifiche apportate a System.Globalization.CultureInfo.CurrentCulture o System.Globalization.CultureInfo.CurrentUICulture verranno riflesse nelle attività che vengono eseguite in un secondo momento in modo asincrono. Questo comportamento è diverso rispetto alle versioni precedenti di .NET Framework, in cui System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture vengono reimpostate in tutte le attività asincrone.

Suggerimento

Le app interessate da questa modifica possono aggirarla impostando in modo esplicito il valore System.Globalization.CultureInfo.CurrentCulture o System.Globalization.CultureInfo.CurrentUICulture desiderato come prima operazione in un'attività asincrona. In alternativa, è possibile acconsentire esplicitamente al comportamento precedente (ovvero non propagare System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) impostando la seguente opzione di compatibilità:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Il problema è stato risolto da WPF in .NET Framework 4.6.2. È stato risolto anche in .NET Framework 4.6 e 4.6.1 mediante KB 3139549. Le applicazioni destinate a .NET Framework 4.6 o versioni successive otterranno automaticamente il comportamento corretto nelle applicazioni WPF: le proprietà System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture vengono mantenute tra operazioni Dispatcher.

Nome	valore
Scope	Secondarie
Versione	4.6
Type	Ridestinazione

API interessate

• CultureInfo.CurrentCulture
• Thread.CurrentCulture
• CultureInfo.CurrentUICulture
• Thread.CurrentUICulture

I nomi di eventi ETW non possono essere diversi solo per il suffisso "Start" o "Stop"

Dettagli

In .NET Framework 4.6 e 4.6.1 il runtime genera una ArgumentException quando due nomi di eventi ETW (Event Tracing for Windows) sono diversi solo per il suffisso “Start” o “Stop”, ad esempio quando un evento è denominato LogUser e un altro LogUserStart. In questo caso, il runtime non può creare l'origine dell'evento, quindi non viene generata alcuna registrazione.

Suggerimento

Per evitare l'eccezione, assicurarsi che non siano presenti nomi di evento che differiscono solo per il suffisso “Start” oppure “Stop”. Questo requisito è stato rimosso a rimosso a partire da .NET Framework 4.6.2 e il runtime può risolvere l'ambiguità di nomi di evento che differiscono solo per il suffisso “Start” e “Stop”.

Nome	valore
Scope	Edge
Versione	4.6
Type	Ridestinazione

Entity Framework

La compilazione di un file edmx di Entity Framework con Visual Studio 2013 può avere esito negativo con errore MSB4062 se si usano le attività EntityDeploySplit o EntityClean

Dettagli

Gli strumenti di MSBuild 12.0 (inclusi in Visual Studio 2013) hanno modificato i percorsi dei file MSBuild, invalidando i vecchi file di destinazioni di Entity Framework. Il risultato è che le attività EntityDeploySplit e EntityClean hanno esito negativo perché non sono in grado di trovare Microsoft.Data.Entity.Build.Tasks.dll. Si noti che questo problema è causato da una modifica del set di strumenti (MSBuild/VS) e non da una modifica di .NET Framework. Si verificherà solo quando si aggiornano gli strumenti di sviluppo, e non aggiornando semplicemente .NET Framework.

Suggerimento

I file di destinazioni di Entity Framework sono stati corretti per supportare il nuovo layout MSBuild a partire da .NET Framework 4.6. L'aggiornamento a tale versione di .NET Framework consentirà di risolvere questo problema. È possibile anche usare questa soluzione alternativa per applicare direttamente una patch ai file di destinazione.

Nome	valore
Scope	Major
Versione	4.5.1
Type	Ridestinazione

JIT

Istruzione IL ret non consentita in un'area try

Dettagli

A differenza del compilatore JIT JIT64, RyuJIT (usato in .NET Framework 4.6) non consente un'istruzione IL ret in un'area try. La restituzione da un'area try non è consentita dalla specifica ECMA-335 e nessun compilatore gestito noto genera tale IL. Tuttavia, il compilatore JIT64 eseguirà tale livello di integrità se viene generato tramite reflection emit.

Suggerimento

Se un'app genera IL che include un codice operativo ret in un'area try, è possibile destinare l'app a .NET Framework 4.5 per usare il compilatore JIT precedente ed evitare l'interruzione. In alternativa, l'IL generato può essere aggiornato per restituire il controllo dopo l'area try.

Nome	valore
Scope	Edge
Versione	4.6
Type	Ridestinazione

Nuovo compilatore JIT a 64 bit in .NET Framework 4.6

Dettagli

A partire da .NET Framework 4.6, viene usato un nuovo compilatore JIT a 64 bit per la compilazione JIT. In alcuni casi, viene generata un'eccezione imprevista o si nota un comportamento diverso rispetto all'esecuzione di un'app con il compilatore a 32 bit o il compilatore precedente JIT a 64 bit. Questa modifica non riguarda il compilatore JIT a 32 bit. Le differenze note includono quanto segue:

• In determinate condizioni, un'operazione di conversione unboxing può generare NullReferenceException nelle build di rilascio con l'ottimizzazione attivata.
• In alcuni casi l'esecuzione del codice di produzione in un corpo del metodo di grandi dimensioni può generare StackOverflowException.
• In determinate condizioni, le strutture passate a un metodo vengono considerate come tipi riferimento piuttosto che tipi valore nelle build di versione. Una delle manifestazioni di questo problema è che i singoli elementi in una raccolta vengono visualizzati in un ordine imprevisto.
• In determinate condizioni, il confronto dei valori di UInt16 con il set di bit elevato non è corretto se l'ottimizzazione è abilitata.
• In determinate condizioni, in particolare durante l'inizializzazione dei valori della matrice, è possibile che l'inizializzazione della memoria con l'istruzione IL OpCodes.Initblk venga eseguita con un valore non corretto. Ciò può generare un'eccezione non gestita o un output non corretto.
• In alcuni casi rari, un test condizionale dei bit può restituire il valore Boolean non corretto o generare un'eccezione se sono abilitate le ottimizzazioni del compilatore.
• In determinate condizioni, se un'istruzione if viene usata per testare una condizione prima di immettere un blocco try e in uscita dal blocco try, e la stessa condizione viene valutata nel blocco catch o finally, il nuovo compilatore JIT a 64 bit rimuove la condizione if dal blocco catch o finally quando ottimizza il codice. Di conseguenza, il codice contenuto nell'istruzione if nel blocco catch o finally viene eseguita in modo non condizionale.

Suggerimento

Mitigazione dei problemi noti
Se si verificano i problemi elencati in precedenza, è possibile risolverli effettuando una delle operazioni seguenti:

• Eseguire l'aggiornamento a .NET Framework 4.6.2. Il nuovo compilatore a 64 bit incluso in .NET Framework 4.6.2 risolve tutti questi problemi noti.

• Assicurarsi che la versione di Windows venga aggiornata tramite l'esecuzione di Windows Update. Gli aggiornamenti dei servizi per .NET Framework 4.6 e 4.6.1 risolvono tutti questi problemi, ad eccezione di NullReferenceException in un'operazione di conversione unboxing.

• Eseguire la compilazione con la versione precedente del compilatore JIT a 64 bit. Vedere la sezione Mitigazione di altri problemi per altre informazioni su come eseguire questa operazione. Mitigazione di altri problemi
  Nel caso di qualsiasi altra differenza nel comportamento tra il codice compilato con la versione precedente del compilatore a 64 bit e quello compilato con la versione nuova, oppure tra le versioni di debug e rilascio dell'app compilate entrambe con il nuovo compilatore JIT a 64 bit, è possibile eseguire le operazioni seguenti per compilare l'app con la versione precedente del compilatore JIT a 64 bit:

• In base all'applicazione, è possibile aggiungere l'elemento < al file di configurazione dell'applicazione. Le operazioni seguenti consentono di disattivare la compilazione con il nuovo compilatore JIT a 64 bit e usare invece il compilatore JIT a 64 bit legacy.

  <?xml version ="1.0"?>
  <configuration>
    <runtime>
     <useLegacyJit enabled="1" />
    </runtime>
  </configuration>
  

• Per ogni utente è possibile aggiungere un valore REG_DWORD denominato useLegacyJit per la chiave HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework del Registro di sistema. Il valore 1 abilita il compilatore JIT a 64 bit legacy, mentre il valore 0 lo disattiva e consente di abilitare il nuovo compilatore JIT a 64 bit.

• Per ogni macchina è possibile aggiungere un valore REG_DWORD denominato useLegacyJit per la chiave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework del Registro di sistema. Il valore 1 abilita il compilatore JIT a 64 bit legacy, mentre il valore 0 lo disabilita e consente di abilitare il nuovo compilatore JIT a 64 bit. È possibile inoltre inviare i dettagli sul problema segnalando un bug in Microsoft Connect.

Nome	valore
Scope	Edge
Versione	4.6
Type	Ridestinazione

Rete

Convalida dell'OID EKU del certificato

Dettagli

A partire da .NET Framework 4.6, le classi SslStream o ServicePointManager eseguono la convalida dell'oggetto identificatore (OID) dell'utilizzo chiavi avanzato (EKU). Un'estensione di utilizzo chiavi avanzato (EKU) è una raccolta di identificatori di oggetto (OID) che indica le applicazioni che usano la chiave. La convalida dell'OID EKU usa callback del certificato remoto per assicurarsi che il certificato remoto abbia gli OID corretti per lo scopo previsto.

Suggerimento

Se questa modifica non è opportuna, è possibile disabilitare la convalida dell'OID EKU del certificato aggiungendo l'opzione seguente a <AppContextSwitchOverrides> nella sezione ` del file di configurazione dell'app:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontCheckCertificateEKUs=true" />
</runtime>

Importante

Questa impostazione è disponibile solo per la compatibilità con le versioni precedenti. Il suo uso non è altrimenti consigliato.

Nome	valore
Scope	Secondarie
Versione	4.6
Type	Ridestinazione

API interessate

• System.Net.Security.SslStream
• System.Net.ServicePointManager
• System.Net.Http.HttpClient
• System.Net.Mail.SmtpClient
• System.Net.HttpWebRequest
• System.Net.FtpWebRequest

Solo i protocolli Tls 1.0, 1.1 e 1.2 sono supportati in System.Net.ServicePointManager e System.Net.Security.SslStream

Dettagli

A partire da .NET Framework 4.6, le classi ServicePointManager e SslStream possono usare solo uno dei tre protocolli seguenti: Tls1.0, Tls1.1 o Tls1.2. Il protocollo SSL 3.0 e la crittografia RC4 non sono supportati.

Suggerimento

La mitigazione consigliata consiste nell'aggiornare l'app sul lato server a Tls1.0, Tls1.1 o Tls1.2. Se ciò non è fattibile o se le app client non funzionano, è possibile usare la classe System.AppContext per rifiutare esplicitamente questa funzionalità in uno dei due modi seguenti:

• Impostando a livello di codice le opzioni di compatibilità su System.AppContext, come spiegato qui.
• Aggiungendo la riga seguente alla sezione <runtime> del file app.config:

<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=true"/>

Nome	valore
Scope	Secondarie
Versione	4.6
Type	Ridestinazione

API interessate

• SecurityProtocolType.Ssl3
• SslProtocols.None
• SslProtocols.Ssl2
• SslProtocols.Ssl3

TLS 1.x passa per impostazione predefinita il flag SCH_SEND_AUX_RECORD all'API SCHANNEL sottostante

Dettagli

Quando si usa TLS 1.x, .NET Framework si basa sull'API SCHANNEL di Windows sottostante. A partire da .NET Framework 4.6, il flag SCH_SEND_AUX_RECORD viene passato per impostazione predefinita a SCHANNEL. SCHANNEL suddivide di conseguenza i dati da crittografare in due record separati, il primo come un singolo byte e il secondo come n-1 byte. In rari casi, ciò interrompe la comunicazione tra i client e i server esistenti che si basano sul presupposto che i dati risiedano in un singolo record.

Suggerimento

Se questa modifica interrompe la comunicazione con un server esistente, è possibile disabilitare l'invio del flag SCH_SEND_AUX_RECORD e ripristinare il comportamento precedente, che non prevede la suddivisione dei dati in record separati, aggiungendo l'opzione seguente all'elemento <AppContextSwitchOverrides> nella sezione <runtime> del file di configurazione dell'app:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchSendAuxRecord=true" />
</runtime>

Importante

Questa impostazione è disponibile solo per la compatibilità con le versioni precedenti. Il suo uso non è altrimenti consigliato.

Nome	valore
Scope	Edge
Versione	4.6
Type	Ridestinazione

API interessate

• System.Net.Security.SslStream
• System.Net.ServicePointManager
• System.Net.Http.HttpClient
• System.Net.Mail.SmtpClient
• System.Net.HttpWebRequest
• System.Net.FtpWebRequest

Windows Communication Foundation (WCF)

Modifica della chiamata di CreateDefaultAuthorizationContext con un argomento Null

Dettagli

L'implementazione di System.IdentityModel.Policy.AuthorizationContext restituito da una chiamata a System.IdentityModel.Policy.AuthorizationContext.CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) con un argomento authorizationPolicies Null è cambiata in .NET Framework 4.6.

Suggerimento

In rari casi, le app WCF che usano l'autenticazione personalizzata possono riscontrare differenze di comportamento. In questi casi è possibile ripristinare il comportamento precedente in due modi diversi:

• Ricompilare l'app per destinarla a una versione precedente rispetto a .NET Framework 4.6. Per i servizi ospitati in IIS, usare l'elemento <httpRuntime targetFramework="x.x"> per destinare l'app a una versione precedente di .NET Framework.

• Aggiungere la riga seguente alla sezione <appSettings> del file app.config:

  <add key="appContext.SetSwitch:Switch.System.IdentityModel.EnableCachedEmptyDefaultAuthorizationContext" value="true" />
  

Nome	valore
Scope	Secondarie
Versione	4.6
Type	Ridestinazione

API interessate

• AuthorizationContext.CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>)

WinForms

Icon.ToBitmap converte correttamente le icone con frame PNG in oggetti Bitmap

Dettagli

A partire dalle app destinate a .NET Framework 4.6, il metodo Icon.ToBitmap converte correttamente le icone con frame PNG in oggetti Bitmap.

Nelle app destinate a .NET Framework 4.5.2 e alle versioni precedenti, il metodo Icon.ToBitmap genera un'eccezione ArgumentOutOfRangeException se l'oggetto Icon presenta frame PNG.

Questa modifica influisce sulle app che vengono ricompilate per essere destinate a .NET Framework 4.6 e che implementano una gestione speciale per l'eccezione ArgumentOutOfRangeException generata quando un oggetto Icon presenta frame PNG. Quando è in esecuzione su .NET Framework 4.6, la conversione viene completata correttamente, non viene più generata un'eccezione ArgumentOutOfRangeException e quindi non viene più richiamato il gestore di eccezioni.

Suggerimento

Se questo comportamento è indesiderato, è possibile conservare il comportamento precedente aggiungendo l'elemento seguente alla sezione <runtime> del file app.config:

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true" />

Se il file app.config contiene già l'elemento AppContextSwitchOverrides, il nuovo valore deve essere unito con l'attributo value come nell'esempio seguente:

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true;<previous key>=<previous value>" />

Nome	valore
Scope	Secondarie
Versione	4.6
Type	Ridestinazione

API interessate

• Icon.ToBitmap()

Windows Presentation Foundation (WPF)

CurrentCulture non viene mantenuto nelle operazioni Dispatcher di WPF

Dettagli

A partire da .NET Framework 4.6, le modifiche apportate a System.Globalization.CultureInfo.CurrentCulture o System.Globalization.CultureInfo.CurrentUICulture all'interno di un System.Windows.Threading.Dispatcher vanno perdute al termine dell'operazione del dispatcher. In modo analogo, le modifiche apportate a System.Globalization.CultureInfo.CurrentCulture o System.Globalization.CultureInfo.CurrentUICulture all'esterno di un'operazione di Dispatcher potrebbero non essere disponibili quando viene eseguita l'operazione. In pratica, ciò significa che le modifiche System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture potrebbero non essere trasferite tra i callback UI di WPF e altro codice in un'applicazione WPF. Questo è dovuto a una modifica in System.Threading.ExecutionContext in seguito alla quale System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture vengono archiviati nel contesto di esecuzione a partire dalle app destinate a .NET Framework 4.6. Le operazioni del dispatcher WPF archiviano il contesto di esecuzione usato per avviare l'operazione e ripristinano il contesto precedente dopo il completamento dell'operazione. Dato che System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture fanno ora parte di tale contesto, le modifiche di questi elementi all'interno di un'operazione di Dispatcher non vengono mantenute all'esterno dell'operazione.

Suggerimento

Le app interessate da questa modifica possono risolvere il problema archiviando i valori System.Globalization.CultureInfo.CurrentCulture o System.Globalization.CultureInfo.CurrentUICulture desiderati in un campo e controllando che siano impostati i valori corretti di System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture in tutti i corpi delle operazioni del dispatcher (inclusi i gestori di callback degli eventi dell'interfaccia utente). In alternativa, dato che la modifica di ExecutionContext sottostante questa modifica WPF influisce solo sulle app destinate a .NET Framework 4.6 o versione successiva, è possibile evitare il problema destinando le app a .NET Framework 4.5.2. Anche le app destinate a .NET Framework 4.6 o versioni successive possono evitare il problema impostando la seguente opzione di compatibilità:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Il problema è stato risolto da WPF in .NET Framework 4.6.2. È stato risolto anche in .NET Framework 4.6 e 4.6.1 mediante KB 3139549. Le applicazioni destinate a .NET Framework 4.6 o versioni successive otterranno automaticamente il comportamento corretto nelle applicazioni WPF: le proprietà System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture vengono mantenute tra operazioni Dispatcher.

Nome	valore
Scope	Secondarie
Versione	4.6
Type	Ridestinazione

L'arrotondamento del layout dei margini in WPF è stato modificato

Dettagli

Il modo in cui i margini vengono arrotondati e i bordi e lo sfondo al loro interno vengono modificati. Come conseguenza di questo cambiamento:

• La larghezza o l'altezza degli elementi può aumentare o diminuire al massimo di un pixel.
• La posizione di un oggetto può cambiare al massimo di un pixel.
• Gli elementi centrati possono risultare decentrati in orizzontale o in verticale al massimo di un pixel. Per impostazione predefinita, questo nuovo layout è disponibile solo per app destinate a .NET Framework 4.6.

Suggerimento

Poiché questa modifica tende a eliminare il ritaglio del lato destro o inferiore dei controlli WPF a DPI elevati, le app destinate a versioni precedenti di .NET Framework ma eseguite su .NET Framework 4.6 possono adottare questo nuovo comportamento aggiungendo la riga seguente alla sezione <runtime> del file app.config:

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

Le app che usano .NET Framework 4.6, ma che richiedono che il rendering dei controlli WPF sia eseguito tramite l'algoritmo di layout precedente, possono aggiungere la riga seguente alla sezione <runtime> del file app.config per raggiungere tale scopo:

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

Nome	valore
Scope	Secondarie
Versione	4.6
Type	Ridestinazione

XML, XSLT

XmlWriter genera un'eccezione per le coppie di surrogati non valide

Dettagli

Per le app destinate a .NET Framework 4.5.2 o a versioni precedenti, se si scrive una coppia di surrogati non valida usando la gestione dei fallback delle eccezioni, non viene sempre generata un'eccezione. Per le applicazioni destinate a .NET Framework 4.6, il tentativo di scrivere una coppia di surrogati non valida genera System.ArgumentException.

Suggerimento

Se necessario, questa interruzione può essere evitata specificando come destinazione .NET Framework 4.5.2 o versioni precedenti. In alternativa, le coppie di surrogati non valide possono essere pre-elaborate in un xml valido prima di scriverle.

Nome	valore
Scope	Edge
Versione	4.6
Type	Ridestinazione

API interessate

• XmlWriter.WriteAttributeString(String, String)
• XmlWriter.WriteAttributeString(String, String, String)
• XmlWriter.WriteAttributeString(String, String, String, String)
• XmlWriter.WriteAttributeStringAsync(String, String, String, String)
• XmlWriter.WriteCData(String)
• XmlWriter.WriteCDataAsync(String)
• XmlWriter.WriteChars(Char[], Int32, Int32)
• XmlWriter.WriteCharsAsync(Char[], Int32, Int32)
• XmlWriter.WriteComment(String)
• XmlWriter.WriteCommentAsync(String)
• XmlWriter.WriteEntityRef(String)
• XmlWriter.WriteEntityRefAsync(String)
• XmlWriter.WriteRaw(Char[], Int32, Int32)
• XmlWriter.WriteProcessingInstruction(String, String)
• XmlWriter.WriteProcessingInstructionAsync(String, String)
• XmlWriter.WriteRaw(String)
• XmlWriter.WriteRawAsync(Char[], Int32, Int32)
• XmlWriter.WriteRawAsync(String)
• XmlWriter.WriteString(String)
• XmlWriter.WriteStringAsync(String)
• XmlWriter.WriteSurrogateCharEntity(Char, Char)
• XmlWriter.WriteSurrogateCharEntityAsync(Char, Char)
• XmlWriter.WriteValue(String)

La convalida di XSD Schema ora rileva correttamente le violazioni dei vincoli univoci se vengono usate chiavi composte e una chiave è vuota

Dettagli

Le versioni di .NET Framework precedenti alla 4.6 includono un bug a causa del quale la convalida XSD non rileva vincoli univoci per le chiavi composte se una delle chiavi è vuota. Questo problema è stato corretto in .NET Framework 4.6. La convalida sarà più corretta, ma è possibile che la convalida di alcuni file XML abbia esito negativo, diversamente da quanto accadeva in precedenza.

Suggerimento

Se è necessario usare la convalida .NET Framework 4.0 meno restrittiva, l'applicazione da convalidare può essere destinata alla versione 4.5 (o versioni precedenti) di .NET Framework. In caso di ridestinazione a .NET Framework 4.6, tuttavia, è necessario rivedere il codice per assicurarsi che non sia prevista la convalida per le chiavi composte duplicate, come descritto nella descrizione di questo problema.

Nome	valore
Scope	Edge
Versione	4.6
Type	Ridestinazione

.NET Framework 4.6.1

Memoria centrale

Modifica del carattere separatore di percorso nella proprietà FullName degli oggetti ZipArchiveEntry

Dettagli

Per le app destinate a .NET Framework 4.6.1 e versioni successive, il carattere separatore di percorso è stato modificato da una barra rovesciata (“\”) a una barra (“/”) nella proprietà FullName degli oggetti ZipArchiveEntry creati da overload del metodo CreateFromDirectory. Questa modifica garantisce la conformità dell'implementazione .NET alla sezione 4.4.17.1 della specifica relativa al formato di file ZIP e consente agli archivi con estensione ZIP di essere decompressi anche in sistemi non Windows.
La decompressione di un file ZIP creato da un'applicazione che ha come destinazione una versione precedente di .NET Framework nei sistemi operativi non Windows, ad esempio Macintosh, non riesce a mantenere la struttura della directory. Ad esempio, su Macintosh, crea un set di file il cui nome concatena il percorso della directory, insieme a qualsiasi barra rovesciata (“\”) e al nome del file. Di conseguenza, la struttura di directory dei file decompressi non viene mantenuta.

Suggerimento

L'impatto di questa modifica sui file con estensione .zip che vengono decompressi nel sistema operativo Windows dalle API nello spazio dei nomi .NET Framework System.IO dovrebbe essere minimo, poiché queste API possono gestire facilmente una barra ("\") o una barra rovesciata ("/") come carattere separatore di percorso.
Se questa modifica non è accettabile, è possibile rifiutarla esplicitamente aggiungendo un'impostazione di configurazione alla sezione <runtime> del file di configurazione dell'applicazione. L'esempio seguente mostra sia la sezione <runtime> che l'opzione per il rifiuto esplicito Switch.System.IO.Compression.ZipFile.UseBackslash:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=true" />
</runtime>

Inoltre, le app destinate a versioni precedenti di .NET Framework ma eseguite in .NET Framework 4.6.1 e versioni successive possono acconsentire esplicitamente a questo comportamento aggiungendo un'impostazione di configurazione alla sezione <runtime> del file di configurazione dell'applicazione. L'esempio seguente mostra sia la sezione <runtime> che l'opzione per il consenso esplicito Switch.System.IO.Compression.ZipFile.UseBackslash.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=false" />
</runtime>

Nome	valore
Scope	Edge
Versione	4.6.1
Type	Ridestinazione

API interessate

• ZipFile.CreateFromDirectory(String, String)
• ZipFile.CreateFromDirectory(String, String, CompressionLevel, Boolean)
• ZipFile.CreateFromDirectory(String, String, CompressionLevel, Boolean, Encoding)

Windows Communication Foundation (WCF)

Associazione WCF con la modalità di sicurezza TransportWithMessageCredential

Dettagli

A partire da .NET Framework 4.6.1 l'associazione WCF che usa la modalità di sicurezza TransportWithMessageCredential può essere impostata in modo da ricevere i messaggi con intestazioni “a” non firmate per le chiavi di sicurezza asimmetriche. Per impostazione predefinita, le intestazioni “a” non firmate continueranno a essere rifiutate in .NET Framework 4.6.1. Verranno accettate solo se un'applicazione accetta in modo esplicito questa nuova modalità di funzionamento usando l'opzione di configurazione Switch.System.ServiceModel.AllowUnsignedToHeader.

Suggerimento

Poiché è una funzionalità che prevede il consenso esplicito, non dovrebbe influire sul comportamento delle app esistenti.
Per stabilire se il nuovo comportamento deve essere usato o meno, usare l'impostazione di configurazione seguente:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.ServiceModel.AllowUnsignedToHeader=true" />
</runtime>

Nome	valore
Scope	Trasparente
Versione	4.6.1
Type	Ridestinazione

API interessate

• BasicHttpSecurityMode.TransportWithMessageCredential
• BasicHttpsSecurityMode.TransportWithMessageCredential
• SecurityMode.TransportWithMessageCredential
• WSFederationHttpSecurityMode.TransportWithMessageCredential

X509CertificateClaimSet.FindClaims considera tutti gli argomenti claimType

Dettagli

Nelle app destinate a .NET Framework 4.6.1, se un set di attestazioni X509 viene inizializzato da un certificato con più voci DNS nel proprio campo SAN, il metodo System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) cerca di stabilire una corrispondenza con l'argomento claimType con tutte le voci DNS. Per le app destinate a versioni precedenti di .NET Framework, il metodo System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) tenta di stabilire una corrispondenza con l'argomento claimType solo con l'ultima voce DNS.

Suggerimento

Questa modifica riguarda solo le applicazioni destinate a .NET Framework 4.6.1. Questa modifica può essere disabilitata (o abilitata se la destinazione è una versione precedente la 4.6.1) con l'opzione di compatibilità DisableMultipleDNSEntries.

Nome	valore
Scope	Secondarie
Versione	4.6.1
Type	Ridestinazione

API interessate

• X509CertificateClaimSet.FindClaims(String, String)

WinForms

Application.FilterMessage non genera più un'eccezione per le implementazioni rientranti di IMessageFilter.PreFilterMessage

Dettagli

Prima di .NET Framework 4.6.1, una chiamata a FilterMessage(Message) con un PreFilterMessage(Message) che chiamava System.Windows.Forms.Application.AddMessageFilter(IMessageFilter) o System.Windows.Forms.Application.RemoveMessageFilter(IMessageFilter) (contemporaneamente alla chiamata a DoEvents()) avrebbe causato una System.IndexOutOfRangeException.

A partire dalle applicazioni destinate a .NET Framework 4.6.1, questa eccezione non viene più generata e si possono usare filtri rientranti come descritto in precedenza.

Suggerimento

Tenere presente che FilterMessage(Message) non genererà più un'eccezione per il comportamento PreFilterMessage(Message) rientrante descritto in precedenza. Questa condizione influisce solo sulle applicazioni destinate a .NET Framework 4.6.1. Le app destinate a .NET Framework 4.6.1 possono rifiutare esplicitamente questa modifica (o le app destinate a versioni precedenti possono acconsentire esplicitamente) usando l'opzione di compatibilità DontSupportReentrantFilterMessage.

Nome	valore
Scope	Edge
Versione	4.6.1
Type	Ridestinazione

API interessate

• Application.FilterMessage(Message)

Windows Presentation Foundation (WPF)

Le chiamate a System.Windows.Input.PenContext.Disable nei sistemi abilitati per il tocco possono generare ArgumentException

Dettagli

In alcuni casi, le chiamate al metodo System.Windows.Intput.PenContext.Disable interno nei sistemi abilitati per il tocco possono generare una T:System.ArgumentException non gestita a causa della reentrancy.

Suggerimento

Questo problema è stato risolto in .NET Framework 4.7. Per evitare l'eccezione, eseguire l'aggiornamento a una versione di .NET Framework a partire da .NET Framework 4.7.

Nome	valore
Scope	Edge
Versione	4.6.1
Type	Ridestinazione

.NET Framework 4.6.2

ASP.NET

HttpRuntime.AppDomainAppPath genera un'eccezione NullReferenceException

Dettagli

In .NET Framework 4.6.2, il runtime genera una T:System.NullReferenceException durante il recupero di un valore P:System.Web.HttpRuntime.AppDomainAppPath che include caratteri Null. In .NET Framework 4.6.1 e versioni precedenti, il runtime genera una T:System.ArgumentNullException.

Suggerimento

È possibile eseguire una delle operazioni seguenti per rispondere a questa modifica:

• Se l'applicazione è in esecuzione in .NET Framework 4.6.2, gestire T:System.NullReferenceException.
• Eseguire l'aggiornamento a .NET Framework 4.7, che consente di ripristinare il comportamento precedente e genera un'eccezione T:System.ArgumentNullException.

Nome	valore
Scope	Edge
Versione	4.6.2
Type	Ridestinazione

API interessate

• HttpRuntime.AppDomainAppPath

Memoria centrale

Il componente di decrittografia AesCryptoServiceProvider fornisce una trasformazione riutilizzabile

Dettagli

A partire dalle app destinate a .NET Framework 4.6.2, il componente di decrittografia AesCryptoServiceProvider fornisce una trasformazione riutilizzabile. Dopo una chiamata a System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32), la trasformazione viene reinizializzata e può essere riutilizzata. Per le app destinate a versioni precedenti di .NET Framework, il tentativo di riusare il componente di decrittografia chiamando System.Security.Cryptography.CryptoAPITransform.TransformBlock(Byte[], Int32, Int32, Byte[], Int32) dopo una chiamata a System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32) genera un'eccezione CryptographicException o produce dati danneggiati.

Suggerimento

L'impatto di questa modifica dovrebbe essere minimo, dato che questo è il comportamento previsto. Le applicazioni che dipendono dal comportamento precedente lo possono rifiutare esplicitamente aggiungendo l'impostazione di configurazione seguente alla sezione <runtime> del file di configurazione dell'applicazione:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=true"/>
</runtime>

Le applicazioni destinate a versioni precedenti di .NET Framework ma in esecuzione su una versione uguale o successiva a .NET Framework .NET Framework 4.6.2 possono acconsentire esplicitamente a questo comportamento aggiungendo l'impostazione di configurazione seguente alla sezione <runtime> del file di configurazione dell'applicazione:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=false"/>
</runtime>

Nome	valore
Scope	Secondarie
Versione	4.6.2
Type	Ridestinazione

API interessate

• AesCryptoServiceProvider.CreateDecryptor()

Chiamate dei costruttori ClaimsIdentity

Dettagli

A partire da .NET Framework 4.6.2 è stata introdotta una modifica al modo in cui i costruttori ClaimsIdentity con un parametro System.Security.Principal.IIdentity impostano la proprietà System.Security.Claims.ClaimsIdentity.Actor. Se l'argomento System.Security.Principal.IIdentity è un oggetto ClaimsIdentity e la proprietà System.Security.Claims.ClaimsIdentity.Actor di tale oggetto ClaimsIdentity non è null, la proprietà System.Security.Claims.ClaimsIdentity.Actor viene allegata usando il metodo Clone(). In .NET Framework 4.6.1 e versioni precedenti, la proprietà System.Security.Claims.ClaimsIdentity.Actor viene associata come riferimento esistente. In seguito a questa modifica, a partire da .NET Framework 4.6.2, la proprietà System.Security.Claims.ClaimsIdentity.Actor del nuovo oggetto ClaimsIdentity non è uguale alla proprietà System.Security.Claims.ClaimsIdentity.Actor dell'argomento System.Security.Principal.IIdentity del costruttore. In .NET Framework 4.6.1 e versioni precedenti è uguale.

Suggerimento

Se questo comportamento è inaccettabile, è possibile ripristinare il comportamento precedente impostando il commutatore Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity nel file di configurazione dell'applicazione su true. A questo scopo è necessario aggiungere il codice seguente alla sezione <runtime> del file web.config:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity=true" />
  </runtime>
</configuration>

Nome	valore
Scope	Edge
Versione	4.6.2
Type	Ridestinazione

API interessate

• ClaimsIdentity(IIdentity)
• ClaimsIdentity(IIdentity, IEnumerable<Claim>)
• ClaimsIdentity(IIdentity, IEnumerable<Claim>, String, String, String)

Modifica nella normalizzazione del percorso

Dettagli

A partire dalle app destinate a .NET Framework 4.6.2, il modo in cui il runtime normalizza i percorsi è cambiato. La normalizzazione di un percorso implica la modifica della stringa che identifica un percorso o un file in modo che sia conforme a un percorso valido nel sistema operativo di destinazione. In genere, la normalizzazione implica:

• La conversione in forma canonica dei separatori di directory e dei componenti.
• L'applicazione della directory corrente in un percorso relativo.
• La valutazione della directory relativa (.) o della directory padre (..) in un percorso.
• La rimozione di caratteri specificati. Le modifiche seguenti per la normalizzazione del percorso sono abilitate per impostazione predefinita a partire dalle app destinate a .NET Framework 4.6.2:
  • Il runtime viene rinviato alla funzione GetFullPathName del sistema operativo per normalizzare i percorsi.
• La normalizzazione non consiste più nel rimuovere la fine dei segmenti di directory (ad esempio uno spazio alla fine di un nome di directory).
• Supporto per la sintassi del percorso dispositivo in attendibilità totale, tra cui \\.\ e, per le API del file I/O in mscorlib.dll, \\?\.
• Il runtime non convalida i percorsi di sintassi del dispositivo.
• È supportato l'uso della sintassi del dispositivo per accedere ai flussi di dati alternativi. Queste modifiche migliorano le prestazioni, consentendo al contempo ai metodi di accedere a percorsi in precedenza inaccessibili. Le applicazioni destinate a .NET Framework 4.6.1 e versioni precedenti ma in esecuzione in .NET Framework 4.6.2 o versioni successive non sono interessate da questa modifica.

Suggerimento

Le app destinate a .NET Framework 4.6.2 o versioni successive possono rifiutare esplicitamente questa modifica e usare la normalizzazione legacy aggiungendo il codice seguente alla sezione <runtime> del file di configurazione dell'applicazione:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=true" />
</runtime>

Le app destinate a .NET Framework 4.6.1 o versioni precedenti ma in esecuzione su .NET Framework 4.6.2 o versioni successive possono abilitare le modifiche alla normalizzazione del percorso aggiungendo la riga seguente alla sezione <runtime> del file di configurazione dell'applicazione:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false" />
</runtime>

Nome	valore
Scope	Secondarie
Versione	4.6.2
Type	Ridestinazione

CurrentCulture e CurrentUICulture vengono propagate tra le attività

Dettagli

A partire da .NET Framework 4.6, le proprietà System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture sono archiviate in System.Threading.ExecutionContext del thread, che viene propagato tra le operazioni asincrone. Ciò significa che le modifiche apportate a System.Globalization.CultureInfo.CurrentCulture o System.Globalization.CultureInfo.CurrentUICulture verranno riflesse nelle attività che vengono eseguite in un secondo momento in modo asincrono. Questo comportamento è diverso rispetto alle versioni precedenti di .NET Framework, in cui System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture vengono reimpostate in tutte le attività asincrone.

Suggerimento

Le app interessate da questa modifica possono aggirarla impostando in modo esplicito il valore System.Globalization.CultureInfo.CurrentCulture o System.Globalization.CultureInfo.CurrentUICulture desiderato come prima operazione in un'attività asincrona. In alternativa, è possibile acconsentire esplicitamente al comportamento precedente (ovvero non propagare System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) impostando la seguente opzione di compatibilità:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Il problema è stato risolto da WPF in .NET Framework 4.6.2. È stato risolto anche in .NET Framework 4.6 e 4.6.1 mediante KB 3139549. Le applicazioni destinate a .NET Framework 4.6 o versioni successive otterranno automaticamente il comportamento corretto nelle applicazioni WPF: le proprietà System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture vengono mantenute tra operazioni Dispatcher.

Nome	valore
Scope	Secondarie
Versione	4.6
Type	Ridestinazione

API interessate

• CultureInfo.CurrentCulture
• Thread.CurrentCulture
• CultureInfo.CurrentUICulture
• Thread.CurrentUICulture

I nomi di eventi ETW non possono essere diversi solo per il suffisso "Start" o "Stop"

Dettagli

In .NET Framework 4.6 e 4.6.1 il runtime genera una ArgumentException quando due nomi di eventi ETW (Event Tracing for Windows) sono diversi solo per il suffisso “Start” o “Stop”, ad esempio quando un evento è denominato LogUser e un altro LogUserStart. In questo caso, il runtime non può creare l'origine dell'evento, quindi non viene generata alcuna registrazione.

Suggerimento

Per evitare l'eccezione, assicurarsi che non siano presenti nomi di evento che differiscono solo per il suffisso “Start” oppure “Stop”. Questo requisito è stato rimosso a rimosso a partire da .NET Framework 4.6.2 e il runtime può risolvere l'ambiguità di nomi di evento che differiscono solo per il suffisso “Start” e “Stop”.

Nome	valore
Scope	Edge
Versione	4.6
Type	Ridestinazione

Supporto del percorso lungo

Dettagli

A partire dalle app destinate a .NET Framework 4.6.2, i percorsi lunghi (fino a 32 KB di caratteri) sono supportati e il limite di 260 caratteri (o MAX_PATH) per la lunghezza dei percorsi è stato rimosso. Per le app ricompilate con destinazione .NET Framework 4.6.2, i percorsi che in precedenza generavano una System.IO.PathTooLongException a causa di un percorso più lungo di 260 caratteri genereranno ora una System.IO.PathTooLongException solo nelle condizioni seguenti:

• La lunghezza del percorso è maggiore di MaxValue (32.767) caratteri.
• Il sistema operativo restituisce COR_E_PATHTOOLONG o equivalente. Per le app destinate a .NET Framework 4.6.1 e versioni precedenti, il runtime genera automaticamente un'eccezione System.IO.PathTooLongException ogni volta che un percorso supera i 260 caratteri.

Suggerimento

Per le app destinate a .NET Framework 4.6.2, è possibile rifiutare esplicitamente il supporto di percorsi lunghi se non opportuno aggiungendo il codice seguente alla sezione <runtime> del file app.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=true" />
</runtime>

Per le app destinate alle versioni precedenti di .NET Framework, ma eseguite in .NET Framework 4.6.2 o versioni successive è possibile acconsentire esplicitamente al supporto dei percorsi lunghi aggiungendo il codice seguente alla sezione <runtime> del file app.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=false" />
</runtime>

Nome	valore
Scope	Secondarie
Versione	4.6.2
Type	Ridestinazione

I controlli della presenza di due punti nel percorso sono più severi

Dettagli

In .NET Framework 4.6.2 sono state apportate varie modifiche per supportare i percorsi in precedenza non supportati (sia per lunghezza che per formato). I controlli della sintassi corretta del separatore appropriato per le unità (due punti) sono ora più corretti. L'effetto collaterale è però il blocco di alcuni percorsi URI in un gruppo selezionato di API Path in cui l'uso era tollerato.

Suggerimento

Per il passaggio di un URI alle API interessate, modificare prima di tutto la stringa in modo che sia un percorso valido.

• Rimuovere manualmente lo schema dagli URL (ad esempio rimuovere file:// dagli URL).

• Passare l'URI alla classe Uri e usare LocalPath.

In alternativa, è possibile rifiutare esplicitamente la nuova normalizzazione dei percorsi impostando l'opzione di AppContext Switch.System.IO.UseLegacyPathHandling su true.

Nome	valore
Scope	Edge
Versione	4.6.2
Type	Ridestinazione

API interessate

• Path.GetDirectoryName(String)
• Path.GetPathRoot(String)

Sicurezza

RSACng ora carica correttamente le chiavi RSA di dimensioni non standard

Dettagli

Nelle versioni di .NET Framework precedenti alla 4.6.2, i clienti con chiavi di dimensioni non standard per i certificati RSA non possono accedere a queste chiavi tramite i metodi di estensione System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(X509Certificate2) e System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(X509Certificate2). Viene generata un'eccezione System.Security.Cryptography.CryptographicException con il messaggio “La dimensione della chiave specificata non è supportata”. Il problema è stato risolto in .NET Framework 4.6.2. In modo analogo, ImportParameters(RSAParameters) e ImportParameters(RSAParameters) ora funzionano con dimensioni della chiave non standard senza generare eccezioni System.Security.Cryptography.CryptographicException.

Suggerimento

In presenza di logica di gestione delle eccezioni basata sul comportamento precedente in cui viene generata una System.Security.Cryptography.CryptographicException quando vengono usate dimensioni della chiave non standard, valutare la possibilità di rimuoverla.

Nome	valore
Scope	Edge
Versione	4.6.2
Type	Ridestinazione

API interessate

• RSA.ImportParameters(RSAParameters)
• RSACng.ImportParameters(RSAParameters)
• RSACertificateExtensions.GetRSAPrivateKey(X509Certificate2)
• RSACertificateExtensions.GetRSAPublicKey(X509Certificate2)

SignedXml.GetPublicKey restituisce RSACng per net462 (o lightup) senza reindirizzamento della modifica

Dettagli

A partire da .NET Framework 4.6.2, il tipo concreto dell'oggetto restituito dal metodo SignedXml.GetPublicKey modificato (senza dettaglio) da un'implementazione CryptoServiceProvider a un'implementazione Cng. Questo avviene perché l'implementazione è stata modificata dall'uso di certificate.PublicKey.Key all'uso dell'oggetto certificate.GetAnyPublicKey interno che inoltra a RSACertificateExtensions.GetRSAPublicKey.

Suggerimento

A partire dalle applicazioni eseguite in .NET Framework 4.7.1 è possibile usare l'implementazione CryptoServiceProvider usata per impostazione predefinita in .NET Framework 4.6.1 e versioni precedenti, aggiungendo la seguente opzione di configurazione alla sezione runtime del file di configurazione dell'applicazione:

<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.SignedXmlUseLegacyCertificatePrivateKey=true" />

Nome	valore
Scope	Edge
Versione	4.6.2
Type	Ridestinazione

API interessate

• SignedXml.CheckSignatureReturningKey(AsymmetricAlgorithm)

Windows Communication Foundation (WCF)

Possibile deadlock quando si usano servizi rientranti

Dettagli

Può verificarsi un deadlock in un servizio rientrante, che limita le istanze del servizio a un solo thread di esecuzione alla volta. Sono soggetti a questo problema i servizi che includono l'attributo ServiceBehaviorAttribute seguente nel codice:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]

Suggerimento

Per risolvere questo problema, è possibile eseguire le operazioni seguenti:

• Impostare la modalità di concorrenza del servizio su ConcurrencyMode.Single o ConcurrencyMode.Multiple. Ad esempio:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]

• Installare l'aggiornamento più recente di .NET Framework 4.6.2 oppure eseguire l'aggiornamento a una versione successiva di .NET Framework. Viene così disabilitato il flusso di ExecutionContext in OperationContext.Current. Questo comportamento è configurabile ed è equivalente all'aggiunta dell'impostazione dell'app seguente nel file di configurazione:

<appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
</appSettings>

Il valore di Switch.System.ServiceModel.DisableOperationContextAsyncFlow non deve mai essere impostato su false per i servizi Reentrant.

Nome	valore
Scope	Secondarie
Versione	4.6.2
Type	Ridestinazione

API interessate

• System.ServiceModel.ServiceBehaviorAttribute
• ConcurrencyMode.Reentrant

OperationContext.Current può restituire Null in caso di chiamata in una clausola using

Dettagli

OperationContext.Current può restituire null e può essere generata un'eccezione NullReferenceException se vengono soddisfatte tutte le condizioni seguenti:

• Si recupera il valore della proprietà OperationContext.Current in un metodo che restituisce Task o Task<TResult>.
• Si crea un'istanza dell'oggetto OperationContextScope in una clausola using.
• Si recupera il valore della proprietà OperationContext.Current all'interno di using statement. Ad esempio:

using (new OperationContextScope(OperationContext.Current))
{
    // OperationContext.Current is null.
    OperationContext context = OperationContext.Current;

    // ...
}

Suggerimento

Per risolvere questo problema, è possibile eseguire le operazioni seguenti:

• Modificare il codice come indicato di seguito per creare un'istanza di un nuovo oggetto Current non null:

  OperationContext ocx = OperationContext.Current;
  using (new OperationContextScope(OperationContext.Current))
  {
      OperationContext.Current = new OperationContext(ocx.Channel);
  
      // ...
  }
  

• Installare l'aggiornamento più recente di .NET Framework 4.6.2 oppure eseguire l'aggiornamento a una versione successiva di .NET Framework. Viene così disabilitato il flusso di ExecutionContext in OperationContext.Current e ripristinato il comportamento delle applicazioni WCF in .NET Framework 4.6.1 e versioni precedenti. Questo comportamento è configurabile ed è equivalente all'aggiunta dell'impostazione dell'app seguente nel file di configurazione:

  <appSettings>
    <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
  </appSettings>
  

  Se questa modifica non è opportuna e l'applicazione dipende dal flusso del contesto di esecuzione tra i contesti operativi, è possibile abilitare il flusso come indicato di seguito:

  <appSettings>
    <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="false" />
  </appSettings>
  

Nome	valore
Scope	Edge
Versione	4.6.2
Type	Ridestinazione

API interessate

• OperationContext.Current

La sicurezza del trasporto WCF supporta i certificati archiviati usando CNG

Dettagli

A partire dalle applicazioni che hanno come destinazione .NET Framework 4.6.2, la sicurezza del trasporto WCF supporta i certificati archiviati usando la libreria di crittografia di Windows (CNG). Questo supporto è limitato ai certificati con una chiave pubblica che ha un esponente di lunghezza non superiore a 32 bit. Quando un'applicazione è destinata a .NET Framework 4.6.2, questa funzionalità è attivata per impostazione predefinita. Nelle versioni precedenti di .NET Framework il tentativo di usare i certificati X509 con un provider di archiviazione chiavi CSG genera un'eccezione.

Suggerimento

Le applicazioni destinate a .NET Framework 4.6.1 e versioni precedenti ma eseguite in .NET Framework 4.6.2 abilitano il supporto per i certificati CNG aggiungendo la riga seguente alla sezione <runtime> del file app.config o web.config:

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

L'operazione può essere eseguita anche con il codice seguente:

private const string DisableCngCertificates = @"Switch.System.IdentityModel.DisableCngCertificate";

AppContext.SetSwitch(disableCngCertificates, false);

Const DisableCngCertificates As String = "Switch.System.IdentityModel.DisableCngCertificates"
AppContext.SetSwitch(disableCngCertificates, False)

Si noti che, grazie a questa modifica, i codici di gestione delle eccezioni che dipendono dal tentativo di avviare una comunicazione protetta con un certificato CNG di esito negativo non verranno più eseguiti.

Nome	valore
Scope	Secondarie
Versione	4.6.2
Type	Ridestinazione

WinForms

Implementazione non corretta di MemberDescriptor.Equals

Dettagli

L'implementazione originale del metodo MemberDescriptor.Equals confronta due diverse proprietà stringa degli oggetti confrontati: la stringa del nome di categoria e la stringa di descrizione. Per risolvere il problema, confrontare Category del primo oggetto con Category del secondo e Description del primo con Description del secondo.

Suggerimento

Se l'applicazione dipende dal fatto che MemberDescriptor.Equals talvolta restituisca false quando i descrittori sono equivalenti ed è destinata a NET Framework 4.6.2 o versione successiva, sono disponibili varie opzioni:

• Apportare modifiche al codice per confrontare i campi Category e Description manualmente oltre a chiamare il metodo MemberDescriptor.Equals.
• Rifiutare esplicitamente questa modifica aggiungendo il valore seguente al file app.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=true" />
</runtime>

Se l'applicazione è destinata a NET Framework 4.6.1 o versioni precedenti ed è in esecuzione in .NET Framework 4.6.2 o versione successiva e si vuole abilitare questa modifica, è possibile impostare l'opzione di compatibilità su false aggiungendo il valore seguente al file app.config:

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

Nome	valore
Scope	Edge
Versione	4.6.2
Type	Ridestinazione

API interessate

• MemberDescriptor.Equals(Object)

Windows Presentation Foundation (WPF)

CurrentCulture non viene mantenuto nelle operazioni Dispatcher di WPF

Dettagli

A partire da .NET Framework 4.6, le modifiche apportate a System.Globalization.CultureInfo.CurrentCulture o System.Globalization.CultureInfo.CurrentUICulture all'interno di un System.Windows.Threading.Dispatcher vanno perdute al termine dell'operazione del dispatcher. In modo analogo, le modifiche apportate a System.Globalization.CultureInfo.CurrentCulture o System.Globalization.CultureInfo.CurrentUICulture all'esterno di un'operazione di Dispatcher potrebbero non essere disponibili quando viene eseguita l'operazione. In pratica, ciò significa che le modifiche System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture potrebbero non essere trasferite tra i callback UI di WPF e altro codice in un'applicazione WPF. Questo è dovuto a una modifica in System.Threading.ExecutionContext in seguito alla quale System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture vengono archiviati nel contesto di esecuzione a partire dalle app destinate a .NET Framework 4.6. Le operazioni del dispatcher WPF archiviano il contesto di esecuzione usato per avviare l'operazione e ripristinano il contesto precedente dopo il completamento dell'operazione. Dato che System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture fanno ora parte di tale contesto, le modifiche di questi elementi all'interno di un'operazione di Dispatcher non vengono mantenute all'esterno dell'operazione.

Suggerimento

Le app interessate da questa modifica possono risolvere il problema archiviando i valori System.Globalization.CultureInfo.CurrentCulture o System.Globalization.CultureInfo.CurrentUICulture desiderati in un campo e controllando che siano impostati i valori corretti di System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture in tutti i corpi delle operazioni del dispatcher (inclusi i gestori di callback degli eventi dell'interfaccia utente). In alternativa, dato che la modifica di ExecutionContext sottostante questa modifica WPF influisce solo sulle app destinate a .NET Framework 4.6 o versione successiva, è possibile evitare il problema destinando le app a .NET Framework 4.5.2. Anche le app destinate a .NET Framework 4.6 o versioni successive possono evitare il problema impostando la seguente opzione di compatibilità:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Il problema è stato risolto da WPF in .NET Framework 4.6.2. È stato risolto anche in .NET Framework 4.6 e 4.6.1 mediante KB 3139549. Le applicazioni destinate a .NET Framework 4.6 o versioni successive otterranno automaticamente il comportamento corretto nelle applicazioni WPF: le proprietà System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture vengono mantenute tra operazioni Dispatcher.

Nome	valore
Scope	Secondarie
Versione	4.6
Type	Ridestinazione