Modifiche di reindirizzamento per la migrazione da .NET Framework 4.5 a 4.6.1

Per problemi di compatibilità delle applicazioni che potrebbero incidere sull'app se si esegue la migrazione da NET Framework 4.5 a 4.6.1, consultare gli argomenti seguenti:

ADO.NET

DbParameter.Precision e DbParameter.Scale sono ora membri virtuali pubblici

Dettagli

Precision e Scale sono implementati come proprietà virtuali pubbliche. Sostituiscono le corrispondenti implementazioni esplicite dell'interfaccia, IDbDataParameter.Precision e IDbDataParameter.Scale.

Suggerimento

Quando si ricompila un provider di database ADO.NET, queste differenze richiederanno l'applicazione della parola chiave 'override' alle proprietà Precision e Scale. Questo è necessario solo quando si ricompilano i componenti. I file binari esistenti continueranno a funzionare.

Nome Valore
Ambito Minorenne
Versione 4.5.1
Tipo Ridestinazione

API interessate

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
Ambito Microsoft Edge
Versione 4,6
Tipo Ridestinazione

API interessate

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
Ambito Microsoft Edge
Versione 4.5
Tipo 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
Ambito Minorenne
Versione 4,6
Tipo Ridestinazione

Core

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 è cambiato da una barra rovesciata ("\") a una barra in avanti ("/") nella FullName proprietà degli ZipArchiveEntry oggetti creati dagli overload del CreateFromDirectory metodo. 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, in Macintosh, crea un set di file il cui nome file concatena il percorso della directory, insieme a qualsiasi barra rovesciata ("\") e al nome file. Di conseguenza, la struttura di directory dei file decompressi non viene mantenuta.

Suggerimento

L'impatto di questa modifica sui file .ZIP decompressi nel sistema operativo Windows in base alle API nello spazio dei nomi .NET Framework System.IO deve essere minimo, poiché queste API possono gestire facilmente una barra rovesciata ("/") o una barra rovesciata ("\") come carattere separatore del 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
Ambito Microsoft Edge
Versione 4.6.1
Tipo Ridestinazione

API interessate

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
Ambito Minorenne
Versione 4,6
Tipo Ridestinazione

API interessate

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 un ArgumentException valore quando due nomi di eventi di Traccia eventi per Windows (ETW) differiscono solo da un suffisso "Start" o "Stop" (come quando un evento è denominato e un altro è denominato LogUserLogUserStart). 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 nessun nome di evento sia diverso solo da un suffisso "Start" o "Stop". Questo requisito viene rimosso a partire da .NET Framework 4.6.2; il runtime può disambiguare i nomi di eventi che differiscono solo per il suffisso "Start" e "Stop".

Nome Valore
Ambito Microsoft Edge
Versione 4,6
Tipo Ridestinazione

L'attributo ObsoleteAttribute viene esportato sia come ObsoleteAttribute che come DeprecatedAttribute negli scenari WinMD

Dettagli

Quando si crea una raccolta di metadati Windows (file con estensione winmd), l'attributo System.ObsoleteAttribute viene esportato sia come System.ObsoleteAttribute che come Windows.Foundation.DeprecatedAttribute.

Suggerimento

La ricompilazione del codice sorgente esistente che usa l'attributo System.ObsoleteAttribute può generare avvisi quando si utilizza tale codice da C++/CX o JavaScript. È sconsigliabile applicare sia System.ObsoleteAttribute che Windows.Foundation.DeprecatedAttribute al codice negli assembly gestiti, perché potrebbero essere generati avvisi di compilazione.

Nome Valore
Ambito Microsoft Edge
Versione 4.5.1
Tipo 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
Ambito Microsoft Edge
Versione 4,6
Tipo 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 influisce sul 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 viene usata un'istruzione if per testare una condizione prima di immettere un try blocco e nell'uscita dal try blocco e la stessa condizione viene valutata nel catch blocco ofinally, il nuovo compilatore JIT a 64 bit rimuove la condizione dal catch blocco o finally quando ottimizza il if 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
Ambito Microsoft Edge
Versione 4,6
Tipo Ridestinazione

MSBuild

L'attiva ResolveAssemblyReference genera ora avvisi in caso di dipendenze con l'architettura non corretta

Dettagli

L'attività genera un avviso, MSB3270, che indica la mancata corrispondenza di un riferimento o di una delle sue dipendenze all'architettura dell'app. Questa situazione si verifica ad esempio se un'app compilata con l'opzione AnyCPU include un riferimento x86. Uno scenario di questo tipo potrebbe provocare un errore dell'app in fase di esecuzione (nel caso descritto, se l'app viene distribuita come processo x64).

Suggerimento

Le possibili conseguenze riguardano le aree seguenti:

  • La ricompilazione genera avvisi che non venivano visualizzati quando l'app veniva compilata con una versione precedente di MSBuild. Tuttavia, dal momento che l'avviso identifica una possibile fonte di errore di runtime, deve essere analizzato e affrontato.
  • Se gli avvisi vengono considerati errori, la compilazione dell'app non verrà completata.
Nome Valore
Ambito Minorenne
Versione 4.5.1
Tipo 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 è indesiderata, è possibile disabilitare la convalida OID EKU del certificato aggiungendo l'opzione seguente all'appContextSwitchOverrides<> nel ` 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
Ambito Minorenne
Versione 4,6
Tipo Ridestinazione

API interessate

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 l'opzione System.AppContextcompat viene attivata su , come illustrato qui.
  • Aggiungendo la riga seguente alla sezione <runtime> del file app.config:
<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=true"/>
Nome Valore
Ambito Minorenne
Versione 4,6
Tipo Ridestinazione

API interessate

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
Ambito Microsoft Edge
Versione 4,6
Tipo Ridestinazione

API interessate

Visual Basic .NET

VB.NET non supporta più la qualificazione parziale dello spazio dei nomi per le API System.Windows

Dettagli

A partire da .NET Framework 4.5.2, i progetti VB.NET non possono specificare API System.Windows con spazi dei nomi parzialmente qualificati. Ad esempio, un riferimento a Windows.Forms.DialogResult avrà esito negativo. Il codice deve invece fare riferimento al nome completo (DialogResult) o importare lo spazio dei nomi specifico e fare semplicemente riferimento a System.Windows.Forms.DialogResult.

Suggerimento

È consigliabile aggiornare il codice in modo che faccia riferimento alle API System.Windows tramite nomi semplici (e importare lo spazio dei nomi rilevante) o con nomi completi.

Nome Valore
Ambito Minorenne
Versione 4.5.2
Tipo Ridestinazione

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
Ambito Minorenne
Versione 4,6
Tipo Ridestinazione

API interessate

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 configurata per ricevere messaggi con intestazioni "to" senza segno per le chiavi di sicurezza asimmetriche. Per impostazione predefinita, le intestazioni "to" 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
Ambito Modalità trasparente
Versione 4.6.1
Tipo Ridestinazione

API interessate

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
Ambito Minorenne
Versione 4.6.1
Tipo Ridestinazione

API interessate

Windows Forms

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

Dettagli

Prima di .NET Framework 4.6.1, chiamare FilterMessage(Message) con un PreFilterMessage(Message) oggetto denominato System.Windows.Forms.Application.AddMessageFilter(IMessageFilter) o System.Windows.Forms.Application.RemoveMessageFilter(IMessageFilter) (anche chiamante DoEvents()) causerebbe un System.IndexOutOfRangeExceptionoggetto .

A partire dalle applicazioni destinate a .NET Framework 4.6.1, questa eccezione non viene più generata e i filtri di nuovo partecipanti, come descritto in precedenza, possono essere usati.

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
Ambito Microsoft Edge
Versione 4.6.1
Tipo Ridestinazione

API interessate

DataObject.GetData ora recupera i dati come UTF-8

Dettagli

Per le app destinate a .NET Framework 4 o che vengono eseguite in .NET Framework 4.5.1 o in versioni precedenti, DataObject.GetData recupera dati in formato HTML sotto forma di stringa ASCII. Di conseguenza, i caratteri non ASCII (i cui codici ASCII sono maggiori di 0x7F) sono rappresentati da due caratteri casuali.

Per le app destinate a .NET Framework 4.5 o versioni successive ed eseguite in .NET Framework 4.5.2, DataObject.GetData recupera i dati formattati HTML come UTF-8, che rappresenta caratteri superiori a 0x7F correttamente.

Suggerimento

Se è stata implementata una soluzione alternativa per il problema di codifica con le stringhe in formato HTML, ad esempio codificando in modo esplicito la stringa HTML recuperata dagli Appunti passandola a System.Text.UTF8Encoding.GetString(Byte[], Int32, Int32), e si intende ridestinare l'app dalla versione 4 alla versione 4.5, è necessario rimuovere questa soluzione alternativa. Se per qualche motivo è necessario il comportamento precedente, l'app può essere destinata a .NET Framework 4.0 per ottenere tale comportamento.

Nome Valore
Ambito Microsoft Edge
Versione 4.5.2
Tipo Ridestinazione

API interessate

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

Dettagli

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

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

Questa modifica influisce sulle app ricompilate per indirizzare .NET Framework 4.6 e che implementano una gestione speciale per l'oggetto ArgumentOutOfRangeException generata quando un oggetto Icon ha fotogrammi 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
Ambito Minorenne
Versione 4,6
Tipo Ridestinazione

API interessate

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
Ambito Microsoft Edge
Versione 4.6.1
Tipo Ridestinazione

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
Ambito Minorenne
Versione 4,6
Tipo Ridestinazione

Il data binding bidirezionale con una proprietà senza un setter pubblico non è supportato

Dettagli

Il data binding per una proprietà senza un setter pubblico non è mai stata uno scenario supportato. A partire da .NET Framework 4.5.1, questo scenario genererà una System.InvalidOperationException. Si noti che la nuova eccezione verrà generata soltanto per le app destinate specificamente a .NET Framework 4.5.1. Per le app destinate a .NET Framework 4.5, la chiamata sarà consentita. Se l'app non è destinata a una versione specifica di .NET Framework, l'associazione verrà considerata unidirezionale.

Suggerimento

È consigliabile aggiornare l'app per usare l'associazione unidirezionale o esporre pubblicamente il setter della proprietà. In alternativa, è possibile destinare l'app a .NET Framework 4.5 per ottenere il comportamento precedente.

Nome Valore
Ambito Minorenne
Versione 4.5.1
Tipo Ridestinazione

API interessate

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
Ambito Minorenne
Versione 4,6
Tipo Ridestinazione

Windows Workflow Foundation (WF)

WorkflowDesigner.Load non rimuove la proprietà del simbolo

Dettagli

Se si usa .NET Framework 4.5 come destinazione in Progettazione flussi di lavoro e si carica un flusso di lavoro 3.5 riallocato con il metodo Load(), viene generata un'eccezione System.Xaml.XamlDuplicateMemberException durante il salvataggio del flusso di lavoro.

Suggerimento

Questo bug si manifesta solo quando si seleziona .NET Framework 4.5 come destinazione in Progettazione flussi di lavoro, quindi è possibile evitarlo impostando WorkflowDesigner.Context.Services.GetService<DesignerConfigurationService>().TargetFrameworkName su .NET Framework 4.0.

In alternativa, è possibile evitare il problema usando il Load(String) metodo per caricare il flusso di lavoro, anziché Load().

Nome Valore
Ambito Principale
Versione 4.5
Tipo Ridestinazione

API interessate

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
Ambito Microsoft Edge
Versione 4,6
Tipo Ridestinazione

API interessate

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
Ambito Microsoft Edge
Versione 4,6
Tipo Ridestinazione