Modifiche di reindirizzamento per la migrazione a .NET Framework 4.7.x
Questo articolo elenca i problemi di compatibilità delle app introdotti in .NET Framework 4.7, 4.7.1e 4.7.2.
.NET Framework 4.7
ASP.NET
HttpRuntime.AppDomainAppPath lancia un'eccezione NullReferenceException
Dettagli
In .NET Framework 4.6.2 il runtime genera un 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 un T:System.ArgumentNullException
.
Suggerimento
È possibile eseguire una delle operazioni seguenti per rispondere a questa modifica:
- Gestire il
T:System.NullReferenceException
se l'applicazione è in esecuzione in .NET Framework 4.6.2. - Esegui l'aggiornamento a .NET Framework 4.7, che ripristina il comportamento precedente e genera un
T:System.ArgumentNullException
.
Nome | Valore |
---|---|
Ambito | Edge |
Versione | 4.6.2 |
Digitare | Reindirizzamento |
API interessate
Limitare le richieste simultanee per sessione
Dettagli
In .NET Framework 4.6.2 e versioni precedenti, ASP.NET esegue le richieste con lo stesso Sessionid in sequenza, e, per impostazione predefinita, ASP.NET rilascia sempre il Sessionid tramite cookie. Se una pagina richiede molto tempo per rispondere, le prestazioni del server risulteranno notevolmente ridotte premendo F5 nel browser. Nella correzione è stato aggiunto un contatore per tenere traccia delle richieste in coda e terminare le richieste quando superano un limite specificato. Il valore predefinito è 50. Se viene raggiunto il limite, verrà registrato un avviso nel registro eventi e potrebbe essere registrata una risposta HTTP 500 nel log IIS.
Suggerimento
Per ripristinare il comportamento precedente, è possibile aggiungere l'impostazione seguente al file web.config per rifiutare esplicitamente il nuovo comportamento.
<appSettings>
<add key="aspnet:RequestQueueLimitPerSession" value="2147483647"/>
</appSettings>
Nome | Valore |
---|---|
Ambito | Edge |
Versione | 4.7 |
Digitare | Reindirizzamento |
Rete
Il valore predefinito di ServicePointManager.SecurityProtocol è SecurityProtocolType.System.Default
Dettagli
A partire dalle app destinate a .NET Framework 4.7, il valore predefinito della proprietà ServicePointManager.SecurityProtocol è SecurityProtocolType.SystemDefault. Questa modifica consente alle API di rete di .NET Framework basate su SslStream (ad esempio FTP, HTTPS e SMTP) di ereditare i protocolli di sicurezza predefiniti dal sistema operativo anziché usare valori hardcoded definiti da .NET Framework. Il valore predefinito varia in base al sistema operativo e a qualsiasi configurazione personalizzata eseguita dall'amministratore di sistema. Per informazioni sul protocollo SChannel predefinito in ogni versione del sistema operativo Windows, vedere Protocolli in TLS/SSL (Schannel SSP).
Per le applicazioni destinate a una versione precedente di .NET Framework, il valore predefinito della proprietà ServicePointManager.SecurityProtocol dipende dalla versione di .NET Framework di destinazione. Per altre informazioni, vedere la sezioneSuggerimento
Questa modifica influisce sulle applicazioni destinate a .NET Framework 4.7 o versioni successive. Se si preferisce usare un protocollo definito anziché basarsi sull'impostazione predefinita del sistema, è possibile impostare in modo esplicito il valore della proprietà ServicePointManager.SecurityProtocol. Se questa modifica è indesiderata, è possibile rifiutarla esplicitamente aggiungendo un'impostazione di configurazione alla sezione <runtime> del file di configurazione dell'applicazione. L'esempio seguente illustra sia la sezione <runtime>
che l'interruttore di disattivazione Switch.System.Net.DontEnableSystemDefaultTlsVersions
:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=true" />
</runtime>
Nome | Valore |
---|---|
Ambito | Minore |
Versione | 4.7 |
Digitare | Reindirizzamento |
API interessate
SslStream supporta gli avvisi TLS
Dettagli
Dopo un handshake TLS non riuscito, verrà generata una System.IO.IOException con un'eccezione interna System.ComponentModel.Win32Exception dalla prima operazione di lettura/scrittura di I/O. Il codice System.ComponentModel.Win32Exception.NativeErrorCode per il System.ComponentModel.Win32Exception può essere mappato all'avviso TLS dell'entità remota utilizzando i codici di errore Schannel per gli avvisi TLS e SSL. Per ulteriori informazioni, vedere RFC 2246: Sezione 7.2.2 Avvisi di errore.
Il comportamento nelle versioni .NET Framework 4.6.2 e precedenti è che il canale di trasporto (in genere la connessione TCP) avrà un timeout durante la scrittura o la lettura se l'altra parte non ha superato l'handshake e immediatamente dopo abbia rifiutato la connessione.
Suggerimento
Le applicazioni che chiamano le API di I/O di rete, ad esempio Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32), devono gestire IOException o System.TimeoutException.
La funzionalità Avvisi TLS è abilitata per impostazione predefinita a partire da .NET Framework 4.7. Le applicazioni destinate alle versioni di .NET Framework dalla versione 4.0 alla 4.6.2 in esecuzione in un sistema .NET Framework 4.7 o versione successiva avranno la funzionalità disabilitata per mantenere la compatibilità.
L'API di configurazione seguente è disponibile per abilitare o disabilitare la funzionalità per le applicazioni .NET Framework 4.6 e successive in esecuzione in .NET Framework 4.7 o versione successiva.
A livello di codice: deve essere la prima operazione eseguita dall'applicazione perché ServicePointManager inizializzerà una sola volta:
AppContext.SetSwitch("TestSwitch.LocalAppContext.DisableCaching", true); // Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2. AppContext.SetSwitch("Switch.System.Net.DontEnableTlsAlerts", true);
Configurazione dell'applicazione:
<runtime> <AppContextSwitchOverrides value="Switch.System.Net.DontEnableTlsAlerts=true"/> <!-- Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2. --> </runtime>
Chiave del Registro di sistema (globale del computer): Impostare il Valore su
false
per abilitare la funzionalità in .NET Framework 4.6 - 4.6.2.Key: HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\AppContext\Switch.System.Net.DontEnableTlsAlerts - Type: String - Value: "true"
Nome | Valore |
---|---|
Ambito | Bordo |
Versione | 4.7 |
Digitare | Ritargetizzazione |
API interessate
- System.Net.Security.SslStream
- System.Net.WebRequest
- System.Net.HttpWebRequest
- System.Net.FtpWebRequest
- System.Net.Mail.SmtpClient
- System.Net.Http
Sicurezza
CspParameters.ParentWindowHandle prevede ora un valore HWND
Dettagli
Il valore ParentWindowHandle, introdotto in .NET Framework 2.0, consente a un'applicazione di registrare un valore di handle della finestra padre in modo che qualsiasi interfaccia utente necessaria per accedere alla chiave, ad esempio una richiesta di PIN o una finestra di dialogo di consenso, venga aperta come figlio modale nella finestra specificata. A partire dalle app destinate a .NET Framework 4.7, un'applicazione Windows Forms può impostare la proprietà ParentWindowHandle con codice simile al seguente:
cspParameters.ParentWindowHandle = form.Handle;
Nelle versioni precedenti di .NET Framework, si prevede che il valore sia un
Suggerimento
Le applicazioni destinate a .NET Framework 4.7 o versioni successive che desiderano registrare una relazione tra finestre padre sono incoraggiate a usare il formato semplificato:
cspParameters.ParentWindowHandle = form.Handle;
Gli utenti che avevano identificato che il valore corretto da passare era l'indirizzo di una posizione di memoria che manteneva il valore form.Handle
possono optare per non utilizzare la modifica del comportamento impostando l'opzione AppContext Switch.System.Security.Cryptography.DoNotAddrOfCspParentWindowHandle
su true
:
- Impostando programmaticamente le opzioni di compatibilità in AppContext, come illustrato qui.
- Aggiungendo la riga seguente alla sezione
<runtime>
del file app.config:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.DoNotAddrOfCspParentWindowHandle=true"/>
</runtime>
Viceversa, gli utenti che desiderano acconsentire esplicitamente al nuovo comportamento nel runtime di .NET Framework 4.7 quando l'applicazione viene caricata nelle versioni precedenti di .NET Framework può impostare l'opzione AppContext su false
.
Nome | Valore |
---|---|
Ambito | Minore |
Versione | 4.7 |
Digitare | Reindirizzamento |
API interessate
SslStream supporta gli avvisi TLS
Dettagli
Dopo un handshake TLS non riuscito, verrà generata una System.IO.IOException con un'eccezione interna System.ComponentModel.Win32Exception dalla prima operazione di lettura/scrittura di I/O. Il codice System.ComponentModel.Win32Exception.NativeErrorCode per il System.ComponentModel.Win32Exception può essere mappato all'avviso TLS proveniente dall'entità remota utilizzando i codici di errore Schannel per gli avvisi TLS e SSL. Per ulteriori informazioni, vedere RFC 2246: Sezione 7.2.2 Avvisi di errore.
Il comportamento in .NET Framework 4.6.2 e versioni precedenti è che il canale di trasporto (in genere la connessione TCP) avrà un timeout durante scrittura o lettura se l'altra parte non ha superato l'handshake e immediatamente dopo ha rifiutato la connessione.
Suggerimento
Le applicazioni che chiamano le API di I/O di rete, ad esempio Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32), devono gestire IOException o System.TimeoutException.
La funzionalità Avvisi TLS è abilitata per impostazione predefinita a partire da .NET Framework 4.7. Le applicazioni destinate alle versioni di .NET Framework dalla versione 4.0 alla 4.6.2 in esecuzione in un sistema .NET Framework 4.7 o versione successiva avranno la funzionalità disabilitata per mantenere la compatibilità.
L'API di configurazione seguente è disponibile per abilitare o disabilitare la funzionalità per le applicazioni .NET Framework 4.6 e successive in esecuzione in .NET Framework 4.7 o versione successiva.
A livello di codice: deve essere la prima operazione eseguita dall'applicazione perché ServicePointManager inizializzerà una sola volta:
AppContext.SetSwitch("TestSwitch.LocalAppContext.DisableCaching", true); // Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2. AppContext.SetSwitch("Switch.System.Net.DontEnableTlsAlerts", true);
AppConfig:
<runtime> <AppContextSwitchOverrides value="Switch.System.Net.DontEnableTlsAlerts=true"/> <!-- Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2. --> </runtime>
Chiave di Registro (a livello macchina): Impostare il Valore su
false
per abilitare la funzionalità in .NET Framework 4.6 - 4.6.2.Key: HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\AppContext\Switch.System.Net.DontEnableTlsAlerts - Type: String - Value: "true"
Nome | Valore |
---|---|
Ambito | Edge |
Versione | 4.7 |
Digitare | Reindirizzamento |
API interessate
- System.Net.Security.SslStream
- System.Net.WebRequest
- System.Net.HttpWebRequest
- System.Net.FtpWebRequest
- System.Net.Mail.SmtpClient
- System.Net.Http
Windows Communication Foundation (WCF)
La serializzazione dei caratteri di controllo con DataContractJsonSerializer è ora compatibile con ECMAScript V6 e V8
Dettagli
In .NET Framework 4.6.2 e versioni precedenti, il System.Runtime.Serialization.Json.DataContractJsonSerializer non serializza alcuni caratteri di controllo speciali, ad esempio \b, \f e \t, in modo compatibile con gli standard ECMAScript V6 e V8. A partire da .NET Framework 4.7, la serializzazione di questi caratteri di controllo è compatibile con ECMAScript V6 e V8.
Suggerimento
Per le app destinate a .NET Framework 4.7, questa funzionalità è abilitata per impostazione predefinita. Se questo comportamento non è auspicabile, è possibile rifiutare esplicitamente questa funzionalità aggiungendo la riga seguente alla sezione <runtime>
del file app.config o web.config:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Runtime.Serialization.DoNotUseECMAScriptV6EscapeControlCharacter=false" />
</runtime>
Nome | Valore |
---|---|
Ambito | Edge |
Versione | 4.7 |
Digitare | Reindirizzamento |
API interessate
- DataContractJsonSerializer.WriteObject(Stream, Object)
- DataContractJsonSerializer.WriteObject(XmlDictionaryWriter, Object)
- DataContractJsonSerializer.WriteObject(XmlWriter, Object)
La sicurezza dei messaggi WCF è ora in grado di usare TLS1.1 e TLS1.2
Dettagli
A partire da .NET Framework 4.7, i clienti possono configurare TLS1.1 o TLS1.2 nella sicurezza dei messaggi WCF oltre a SSL3.0 e TLS1.0 tramite le impostazioni di configurazione dell'applicazione.
Suggerimento
In .NET Framework 4.7 il supporto per TLS1.1 e TLS1.2 nella sicurezza dei messaggi WCF è disabilitato per impostazione predefinita. È possibile abilitarla aggiungendo la riga seguente alla sezione <runtime>
del file app.config o web.config:
<runtime>
<AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols=false;Switch.System.Net.DontEnableSchUseStrongCrypto=false" />
</runtime>
Nome | Valore |
---|---|
Ambito | Bordo |
Versione | 4.7 |
Digitare | Reindirizzamento |
Windows Presentation Foundation (WPF)
Le chiamate a System.Windows.Input.PenContext.Disable nei sistemi abilitati al tocco possono generare un'eccezione ArgumentException
Dettagli
In certi casi, le chiamate al metodo interno System.Windows.Input.PenContext.Disable nei sistemi abilitati al tocco possono generare un T:System.ArgumentException
non gestito a causa della rientranza.
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 | Bordo |
Versione | 4.6.1 |
Digitare | Ritargetizzazione |
NullReferenceException nel codice di gestione delle eccezioni di ImageSourceConverter.ConvertFrom
Dettagli
Un errore nel codice di gestione delle eccezioni per ConvertFrom(ITypeDescriptorContext, CultureInfo, Object) ha causato la generazione di un System.NullReferenceException non corretto anziché dell'eccezione prevista ( System.IO.DirectoryNotFoundException o System.IO.FileNotFoundException). Questa modifica corregge l'errore in modo che il metodo generi ora l'eccezione corretta.
Per impostazione predefinita, tutte le applicazioni destinate a .NET Framework 4.6.2 e versioni precedenti continuano a generare System.NullReferenceException per la compatibilità. Gli sviluppatori che lavorano con .NET Framework 4.7 e versioni successive dovrebbero visualizzare le eccezioni corrette.
Suggerimento
Gli sviluppatori che desiderano ripristinare System.NullReferenceException quando la destinazione è .NET Framework 4.7 o versione successiva possono aggiungere/unire il codice seguente al file di App.config dell'applicazione:
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Media.ImageSourceConverter.OverrideExceptionWithNullReferenceException=true"/>
</runtime>
</configuration>
Nome | Valore |
---|---|
Ambito | Edge |
Versione | 4.7 |
Digitare | Reindirizzamento |
API interessate
Allocazione della griglia WPF dello spazio alle colonne a stella
Dettagli
A partire da .NET Framework 4.7, WPF sostituisce l'algoritmo che Grid utilizza per allocare spazio alle *-colonne. La larghezza effettiva assegnata alle colonne *-verrà modificata in diversi casi:
- Quando una o più colonne *-hanno anche una larghezza minima o massima che sostituisce l'allocazione proporzionale per tale colonna. La larghezza minima può derivare da una dichiarazione MinWidth esplicita o da un minimo implicito ottenuto dal contenuto della colonna. La larghezza massima può essere definita in modo esplicito solo da una dichiarazione MaxWidth.
- Quando una o più *-colonne dichiara un *-peso estremamente grande, con un valore maggiore di 10^298.
- Quando i pesi *sono sufficientemente diversi per incontrare l'instabilità a virgola mobile (overflow, underflow, perdita di precisione).
- Quando l'arrotondamento del layout è abilitato e il valore DPI di visualizzazione effettivo è sufficientemente elevato. Nei primi due casi, le larghezze prodotte dal nuovo algoritmo possono essere notevolmente diverse da quelle prodotte dall'algoritmo precedente; nell'ultimo caso, la differenza sarà al massimo uno o due pixel.
Il nuovo algoritmo corregge diversi bug presenti nell'algoritmo precedente:
L'allocazione totale alle colonne può superare quella della larghezza della griglia. Questo può accadere quando si alloca spazio a una colonna la cui quota proporzionale è inferiore alla sua dimensione minima. L'algoritmo alloca le dimensioni minime, riducendo lo spazio disponibile per altre colonne. Se non ci fossero colonne *-rimaste da allocare, l'allocazione totale risulterà troppo elevata.
L'allocazione totale può non corrispondere alla larghezza della griglia. Questo è il problema duale di #1, che si verifica quando si alloca a una colonna la cui quota proporzionale è maggiore della sua dimensione massima, senza colonne rimanenti che possano compensare l'eccesso.
Due colonne *-possono ricevere allocazioni non proporzionali ai relativi *pesi. Si tratta di una versione più leggera di #1/#2, che si verifica quando si alloca alle colonne A, B e C (in quell'ordine), dove la parte proporzionale di B viola il vincolo minimo (o massimo). Come sopra, questo modifica lo spazio disponibile della colonna C, che riceve una quantità di spazio proporzionalmente inferiore (o superiore) rispetto a quella ottenuta da A.
Le colonne con pesi estremamente grandi (> 10^298) vengono tutte considerate come se avessero peso 10^298. Le differenze proporzionali tra di esse (e tra le colonne con pesi leggermente inferiori) non vengono rispettate.
Le colonne con pesi infiniti non vengono gestite correttamente. In realtà non è possibile impostare un peso su infinito, ma si tratta di una limitazione artificiale. Il codice di allocazione stava provando a gestirlo, ma facendolo male.
Diversi problemi minori evitando l'overflow, l'underflow, la perdita di precisione e problemi simili legati ai numeri in virgola mobile.
Le regolazioni per l'arrotondamento del layout non sono corrette a DPI sufficientemente alti. Il nuovo algoritmo produce risultati che soddisfano i criteri seguenti:
- La larghezza effettiva assegnata a una colonna *-non è mai inferiore alla larghezza minima né maggiore della larghezza massima.
- A ogni *-colonna alla quale non è stata assegnata la larghezza minima o massima viene assegnata una larghezza proporzionale al suo *-peso. Per essere precisi, se due colonne vengono dichiarate rispettivamente con larghezza x* e y* e se nessuna delle due colonne riceve la larghezza minima o massima, le larghezze effettive v e w assegnate alle colonne sono nella stessa proporzione: v / w == x / y.
- La larghezza totale allocata alle colonne *-proporzionali è uguale allo spazio disponibile dopo l'allocazione alle colonne vincolate (fisse, auto e *-colonne allocate alla loro larghezza minima o massima). Può trattarsi di zero, ad esempio se la somma delle larghezze minime supera la larghezza disponibile della griglia.
- Tutte queste istruzioni devono essere interpretate rispetto al layout "ideale". Quando l'arrotondamento del layout è attivo, le larghezze effettive possono differire dalle larghezze ideali fino a un pixel.
Nota
Tutto ciò che riguarda colonne e larghezze in questo articolo si applica anche alle righe e alle altezze.
Suggerimento
Per impostazione predefinita, le app destinate a versioni di .NET Framework a partire da .NET Framework 4.7 vedranno il nuovo algoritmo, mentre le app destinate a .NET Framework 4.6.2 o versioni precedenti vedranno l'algoritmo precedente.
Per eseguire l'override dell'impostazione predefinita, usare l'impostazione di configurazione seguente:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true" />
</runtime>
Il valore true
seleziona l'algoritmo precedente, false
seleziona il nuovo algoritmo.
Nome | Valore |
---|---|
Scopo | Minore |
Versione | 4.7 |
Digitare | Reindirizzamento |
WPF Pointer-Based Touch Stack
Dettagli
Questa modifica aggiunge la possibilità di abilitare uno stack facoltativo di tocco/stilo WPF basato su WM_POINTER. Gli sviluppatori che non abilitano esplicitamente questa opzione non dovrebbero aspettarsi alcun cambiamento nel comportamento del tocco/stilo di WPF. Problemi attualmente noti con lo stack di tocco/stilo basato su WM_POINTER opzionale:
- Nessun supporto per l'inchiostrazione in tempo reale.
- Mentre l'inchiostrazione e StylusPlugins continueranno a funzionare, verranno elaborati nel thread dell'interfaccia utente, il che può portare a prestazioni scarse.
- Modifiche comportamentali dovute a modifiche apportate alla promozione dagli eventi tocco/stilo agli eventi del mouse
- La manipolazione può comportarsi in modo diverso
- Il trascinamento non mostrerà un feedback appropriato per l'input tramite tocco.
- Ciò non influisce sull'input dello stilo
- Non è più possibile avviare il trascina e rilascia con eventi tocco/stilo.
- Ciò può causare potenzialmente l'interruzione della risposta dell'applicazione fino a quando non viene rilevato l'input del mouse.
- Gli sviluppatori, invece, dovrebbero iniziare il trascinamento e rilascio partendo dagli eventi del mouse.
Suggerimento
Gli sviluppatori che desiderano abilitare questo stack possono aggiungere/unire il codice seguente al file di App.config dell'applicazione:
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Input.Stylus.EnablePointerSupport=true"/>
</runtime>
</configuration>
Rimuovendo questo valore o impostando il valore su false, lo stack facoltativo verrà disattivato. Si noti che questo stack è disponibile solo in Windows 10 Creators Update e versioni successive.
Nome | Valore |
---|---|
Ambito | Bordo |
Versione | 4.7 |
Digitare | Ritargetizzazione |
Windows Workflow Foundation (WF)
Checksum dei flussi di lavoro modificati da MD5 a SHA1
Dettagli
Per supportare il debug con Visual Studio, il runtime del flusso di lavoro genera un checksum per un'istanza del flusso di lavoro usando un algoritmo hash. Nel .NET Framework 4.6.2 e nelle versioni precedenti, l'hashing del checksum dei workflow utilizzava l'algoritmo MD5, il che causava problemi nei sistemi dove FIPS era abilitato. A partire da .NET Framework 4.7, l'algoritmo è SHA1. Se il codice ha salvato in modo permanente questi checksum, saranno incompatibili.
Suggerimento
Se il codice non riesce a caricare le istanze del flusso di lavoro a causa di un errore di checksum, provare ad attivare l'opzione AppContext
"Switch.System.Activities.UseMD5ForWFDebugger" su true. Nel codice:
System.AppContext.SetSwitch("Switch.System.Activities.UseMD5ForWFDebugger", true);
Oppure nella configurazione:
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Activities.UseMD5ForWFDebugger=true" />
</runtime>
</configuration>
Nome | Valore |
---|---|
Ambito | Minore |
Versione | 4.7 |
Digitare | Reindirizzamento |
.NET Framework 4.7.1
ASP.NET
miglioramenti dell'accessibilità di ASP.NET in .NET Framework 4.7.1
Dettagli
A partire da .NET Framework 4.7.1, ASP.NET ha migliorato il funzionamento dei controlli Web ASP.NET con la tecnologia di accessibilità in Visual Studio per supportare meglio i clienti ASP.NET. Di seguito sono riportate le modifiche seguenti:
- Modifiche per implementare modelli di accessibilità dell'interfaccia utente mancanti nei controlli, ad esempio la finestra di dialogo Aggiungi campo nella procedura guidata Visualizzazione Dettagli o la finestra di dialogo Configura ListView della procedura guidata ListView.
- Modifiche per migliorare la visualizzazione in modalità a contrasto elevato, come l'Editor dei campi del Pager dati.
- Modifiche per migliorare le esperienze di navigazione tramite tastiera per i controlli, come la finestra di dialogo Campi nella procedura guidata Modifica campi del controllo cercapersone DataPager, la finestra di dialogo Configura ObjectContext o la finestra di dialogo Configura selezione dati della procedura guidata Configura origine dati.
Suggerimento
Come acconsentire esplicitamente o rifiutare queste modifiche Per consentire a Visual Studio Designer di trarre vantaggio da queste modifiche, è necessario eseguirla in .NET Framework 4.7.1 o versione successiva. L'applicazione Web può trarre vantaggio da queste modifiche in uno dei modi seguenti:
- Installare Visual Studio 2017 15.3 o versione successiva, che supporta le nuove funzionalità di accessibilità con il seguente interruttore AppContext per impostazione predefinita.
- Rifiutare esplicitamente i comportamenti di accessibilità legacy aggiungendo l'opzione
Switch.UseLegacyAccessibilityFeatures
AppContext alla sezione<runtime>
nel file devenv.exe.config e impostandola sufalse
, come illustrato nell'esempio seguente.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
...
<!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false' -->
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false" />
...
</runtime>
</configuration>
Le applicazioni destinate a .NET Framework 4.7.1 o versioni successive e vogliono mantenere il comportamento di accessibilità legacy possono acconsentire esplicitamente all'uso delle funzionalità di accessibilità legacy impostando in modo esplicito questa opzione AppContext su true
.
Nome | Valore |
---|---|
Ambito | Minore |
Versione | 4.7.1 |
Digitare | Reindirizzamento |
Nucleo
Eccezioni del thread SerialPort in background
Dettagli
I thread in background creati con flussi SerialPort non terminano più il processo quando vengono generate eccezioni del sistema operativo.
Nelle applicazioni destinate al .NET Framework 4.7 e versioni precedenti, un processo viene terminato quando viene generata un'eccezione del sistema operativo in un thread in background creato con un flusso SerialPort.
Nelle applicazioni destinate a .NET Framework 4.7.1 o versione successiva, i thread in background attendono eventi del sistema operativo correlati alla porta seriale attiva e potrebbero arrestarsi improvvisamente in alcuni casi, come la rimozione improvvisa della porta seriale.
Suggerimento
Per le app destinate a .NET Framework 4.7.1, è possibile rifiutare esplicitamente la gestione delle eccezioni se non è consigliabile aggiungendo quanto segue alla sezione <runtime>
del file app.config
:
<runtime>
<AppContextSwitchOverrides value="Switch.System.IO.Ports.DoNotCatchSerialStreamThreadExceptions=true" />
</runtime>
Per le app destinate a versioni precedenti di .NET Framework, ma eseguite in .NET Framework 4.7.1 o versioni successive, è possibile acconsentire esplicitamente alla gestione delle eccezioni aggiungendo quanto segue alla sezione <runtime>
del file app.config
:
<runtime>
<AppContextSwitchOverrides value="Switch.System.IO.Ports.DoNotCatchSerialStreamThreadExceptions=false" />
</runtime>
Nome | Valore |
---|---|
Ambito | Minore |
Versione | 4.7.1 |
Digitare | Reindirizzamento |
API interessate
ServiceBase non propaga le eccezioni OnStart
Dettagli
In .NET Framework 4.7 e versioni precedenti le eccezioni generate all'avvio del servizio non vengono propagate al chiamante di ServiceBase.Run.
A partire dalle applicazioni che mirano al .NET Framework 4.7.1, il runtime propaga le eccezioni a ServiceBase.Run per i servizi che non riescono a partire.
Suggerimento
All'avvio del servizio, se è presente un'eccezione, tale eccezione verrà propagata. Ciò dovrebbe aiutare a diagnosticare i casi in cui i servizi non vengono avviati.
Se questo comportamento è indesiderato, è possibile rifiutarlo esplicitamente aggiungendo l'elemento AppContextSwitchOverrides
seguente alla sezione runtime
del file di configurazione dell'applicazione:
<AppContextSwitchOverrides value="Switch.System.ServiceProcess.DontThrowExceptionsOnStart=true" />
Se l'applicazione è destinata a una versione precedente alla 4.7.1 ma si vuole avere questo comportamento, aggiungere l'elemento AppContextSwitchOverrides
seguente alla sezione runtime
del file di configurazione dell'applicazione:
<AppContextSwitchOverrides value="Switch.System.ServiceProcess.DontThrowExceptionsOnStart=false" />
Nome | Valore |
---|---|
Ambito | Minore |
Versione | 4.7.1 |
Digitare | Ritargetizzazione |
API interessate
Sicurezza
Gli algoritmi SignedXML e SignedXMS predefiniti sono stati modificati in SHA256
Dettagli
In .NET Framework 4.7 e versioni precedenti, SignedXML e SignedCMS utilizzano per impostazione predefinita SHA1 per alcune operazioni. A partire da .NET Framework 4.7.1, SHA256 è abilitato per impostazione predefinita per queste operazioni. Questa modifica è necessaria perché SHA1 non è più considerato sicuro.
Suggerimento
Esistono due nuovi valori di cambio di contesto per controllare se SHA1 (non sicuro) o SHA256 viene usato per impostazione predefinita:
- Switch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithms
- Switch.System.Security.Cryptography.Pkcs.UseInsecureHashAlgorithms Per le applicazioni destinate a .NET Framework 4.7.1 e versioni successive, se l'uso di SHA256 è indesiderato, è possibile ripristinare l'impostazione predefinita su SHA1 aggiungendo l'opzione di configurazione seguente alla sezione runtime
del file di configurazione dell'app:
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithms=true;Switch.System.Security.Cryptography.Pkcs.UseInsecureHashAlgorithms=true" />
Per le applicazioni destinate a .NET Framework 4.7 e versioni precedenti, è possibile acconsentire esplicitamente a questa modifica aggiungendo l'opzione di configurazione seguente alla sezione runtime del file di configurazione dell'app:
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithms=false;Switch.System.Security.Cryptography.Pkcs.UseInsecureHashAlgorithms=false" />
Nome | Valore |
---|---|
Scopo | Minore |
Versione | 4.7.1 |
Digitare | Reindirizzamento |
API interessate
- System.Security.Cryptography.Pkcs.CmsSigner
- System.Security.Cryptography.Xml.SignedXml
- System.Security.Cryptography.Xml.Reference
SignedXml.GetPublicKey restituisce RSACng su net462 (o lightup) senza modifiche di reindirizzamento
Dettagli
A partire da .NET Framework 4.6.2, il tipo concreto dell'oggetto restituito dal metodo SignedXml.GetPublicKey è stato modificato (senza una modifica apportata) da un'implementazione CryptoServiceProvider a un'implementazione Cng. Ciò è dovuto al fatto che l'implementazione è cambiata dall'uso di certificate.PublicKey.Key
all'uso del certificate.GetAnyPublicKey
interno che inoltra a RSACertificateExtensions.GetRSAPublicKey.
Suggerimento
A partire dalle app in esecuzione 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 l'opzione di configurazione seguente alla sezione runtime del file di configurazione dell'app:
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.SignedXmlUseLegacyCertificatePrivateKey=true" />
Nome | Valore |
---|---|
Ambito | Edge |
Versione | 4.6.2 |
Digitare | Reindirizzamento |
API interessate
Windows Communication Foundation (WCF)
Accessibilità migliorata per alcuni strumenti di .NET SDK
Dettagli
In .NET Framework SDK 4.7.1 gli strumenti SvcConfigEditor.exe e SvcTraceViewer.exe sono stati migliorati risolvendo vari problemi di accessibilità. La maggior parte di questi problemi era di piccole dimensioni, ad esempio un nome non definito o alcuni modelli di automazione interfaccia utente non implementati correttamente. Sebbene molti utenti non siano consapevoli di questi valori non corretti, i clienti che usano tecnologie assistive come le utilità per la lettura dello schermo troveranno questi strumenti del SDK più accessibili. Certamente, queste correzioni modificano alcuni comportamenti precedenti, come l'ordine di messa a fuoco della tastiera. Per ottenere tutte le correzioni di accessibilità in questi strumenti, è possibile eseguire le operazioni seguenti nel file app.config:
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false"/>
</runtime>
Nome | Valore |
---|---|
Ambito | Bordo |
Versione | 4.7.1 |
Digitare | Ritargetizzazione |
Windows Forms
Miglioramenti dell'accessibilità nei controlli Windows Form
Dettagli
Windows Form sta migliorando il funzionamento con le tecnologie di accessibilità per supportare meglio i clienti di Windows Form. Queste includono le modifiche seguenti a partire da .NET Framework 4.7.1:
- Modifiche per migliorare la visualizzazione durante la modalità a contrasto elevato.
- Modifiche per migliorare l'esperienza di navigazione delle proprietà. I miglioramenti del browser delle proprietà includono:
- Migliore navigazione tramite tastiera nei vari menu a discesa.
- Riduzione delle tabulazioni non necessarie.
- Migliore segnalazione dei tipi di controllo.
- Miglioramento del comportamento del narratore.
- Modifiche per implementare modelli di accessibilità dell'interfaccia utente mancanti nei controlli.
Suggerimento
Come acconsentire esplicitamente o rifiutare queste modifiche Affinché l'applicazione possa trarre vantaggio da queste modifiche, deve essere eseguita in .NET Framework 4.7.1 o versione successiva. L'applicazione può trarre vantaggio da queste modifiche in uno dei modi seguenti:
- Viene ricompilato per usare .NET Framework 4.7.1. Queste modifiche all'accessibilità sono abilitate per impostazione predefinita nelle applicazioni Windows Form destinate a .NET Framework 4.7.1 o versioni successive.
- Esclude esplicitamente i comportamenti di accessibilità legacy aggiungendo il seguente switch AppContext alla sezione
<runtime>
del file app.config e impostandolo sufalse
, come illustrato nell'esempio seguente.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7"/>
</startup>
<runtime>
<!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false -->
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false" />
</runtime>
</configuration>
Le applicazioni destinate a .NET Framework 4.7.1 o versioni successive e vogliono mantenere il comportamento di accessibilità legacy possono acconsentire esplicitamente all'uso delle funzionalità di accessibilità legacy impostando in modo esplicito questa opzione AppContext su true
.
Per una panoramica dell'automazione interfaccia utente, vedere Panoramica automazione interfaccia utente.
Aggiunto supporto per i modelli e le proprietà di UI Automation
I client di accessibilità possono sfruttare le nuove funzionalità di accessibilità di WinForms usando modelli di chiamata comuni e descritti pubblicamente. Questi modelli non sono specifici di WinForms. Ad esempio, i client di accessibilità possono chiamare il metodo QueryInterface sull'interfaccia IAccessible (MAAS) per ottenere un'interfaccia IServiceProvider. Se questa interfaccia è disponibile, i client possono usare il relativo metodo QueryService per richiedere un'interfaccia IAccessibleEx. Per ulteriori informazioni, vedere Utilizzo di IAccessibleEx da un Client. A partire da .NET Framework 4.7.1, IServiceProvider e IAccessibleEx (se applicabile) sono disponibili per gli oggetti di accessibilità WinForms.
.NET Framework 4.7.1 aggiunge il supporto per i modelli e le proprietà di automazione interfaccia utente seguenti:
I controlli ToolStripSplitButton e ComboBox supportano il pattern di Espansione/Contrazione .
Il controllo
dispone di un valore della proprietà ControlType . Il controllo ToolStripItem supporta la proprietà NameProperty e il pattern Expand/Collapse.
Il controllo ToolStripDropDownItem supporta AccessibleEvents che indica StateChange e NameChange quando l'elenco a discesa viene espanso o compresso.
Il controllo ToolStripDropDownButton ha una proprietà di tipo di controllo con valore ControlType.MenuItem.
Il controllo DataGridViewCheckBoxCell supporta il TogglePattern.
I controlli NumericUpDown e DomainUpDown supportano la proprietà NameProperty e hanno un ControlType di tipo di ControlType.Spinner.
Miglioramenti al controllo PropertyGrid .NET Framework 4.7.1 aggiunge i miglioramenti seguenti al controllo PropertyBrowser:Il pulsante Dettagli nella finestra di dialogo di errore visualizzata quando l'utente immette un valore non corretto nel controllo PropertyGrid supporta il modello Espandi/Comprimi, le notifiche di modifica dello stato e del nome e una proprietà ControlType con un valore di ControlType.MenuItem.
Il riquadro dei messaggi visualizzato quando il pulsante Dettagli della finestra di dialogo degli errori è ora accessibile tramite tastiera e consente al Narratore di annunciare il contenuto del messaggio di errore.
Il AccessibleRole di righe nel controllo PropertyGrid è stato modificato da "Riga" a "Cella". La cella viene mappata su "UIA ControlType 'DataItem'", che consente di supportare i tasti di scelta rapida appropriati e gli annunci dell'Assistente vocale.
Le righe di controllo PropertyGrid che rappresentano gli elementi dell'intestazione quando il controllo PropertyGrid ha una proprietà PropertySort impostata su PropertySort.Categorized hanno un valore della proprietà ControlType di ControlType.Button.
Le righe di controllo
che rappresentano gli elementi di intestazione quando il controllo ha la proprietà impostata su supportano il pattern Espandi/Comprimidi . Miglioramento dello spostamento tramite tastiera tra la griglia e la barra degli strumenti sopra di essa. Premendo "MAIUSC+TAB" si seleziona ora il primo pulsante Della barra degli strumenti, anziché l'intera barra degli strumenti.
I controlli PropertyGrid visualizzati in modalità contrasto elevato ora disegnano un rettangolo di messa a fuoco intorno al pulsante della barra degli strumenti (ToolBar) che corrisponde al valore corrente della proprietà PropertySort.
PropertyGrid controlli visualizzati in modalità contrasto elevato e con una proprietà PropertySort impostata su PropertySort.Categorized ora visualizzeranno lo sfondo delle intestazioni di categoria in un colore altamente contrastante.
I controlli di PropertyGrid differenziano meglio gli elementi della barra degli strumenti con il focus da quelli che indicano il valore corrente della proprietà PropertySort. Questa correzione è costituita da una modifica a contrasto elevato e da una modifica per scenari non a contrasto elevato.
Gli elementi della barra degli strumenti (PropertyGrid) che indicano il valore corrente della proprietà PropertySort supportano il TogglePattern.
Migliorato il supporto per l'Assistente vocale nel distinguere l'allineamento selezionato nel Selettore di allineamento.
Quando un controllo PropertyGrid vuoto viene visualizzato in un modulo, ora riceverà il fuoco, cosa che in precedenza non accadeva.
Uso dei colori definiti dal sistema operativo nei temi a contrasto elevato
- I controlli Button e CheckBox con la proprietà FlatStyle impostata su FlatStyle.System, che è lo stile predefinito, ora usano i colori definiti dal sistema operativo nel tema a contrasto elevato quando selezionato. In precedenza, i colori di testo e di sfondo non erano in contrasto e erano difficili da leggere.
- I controlli Button, CheckBox, RadioButton, Label, LinkLabele GroupBox, con la proprietà Enabled impostata su false, hanno utilizzato un colore ombreggiato per rendere il testo nei temi a contrasto elevato, risultando in un contrasto ridotto rispetto allo sfondo. Ora questi controlli utilizzano il colore "Testo disabilitato" definito dal sistema operativo (OS). Questa correzione si applica ai controlli con la proprietà
FlatStyle
impostata su un valore diverso da FlatStyle.System. Il rendering di questi ultimi controlli viene eseguito dal sistema operativo. - DataGridView ora esegue il rendering di un rettangolo visibile intorno al contenuto della cella con lo stato attivo corrente. In precedenza, questo non era visibile in determinati temi a contrasto elevato.
- ToolStripMenuItem I controlli con la proprietà Enabled impostata su false ora usano il colore «Testo disabilitato» definito dal sistema operativo.
- I controlli ToolStripMenuItem con la proprietà Checked impostata su vero eseguono ora il rendering del segno di spunta associato in un colore di sistema contrastante. In precedenza, il colore del segno di spunta non aveva un contrasto sufficiente e non era visibile nei temi ad alto contrasto. NOTA: Windows 10 ha modificato i valori per alcuni colori di sistema a contrasto elevato. Windows Form Framework si basa sul framework Win32. Per un'esperienza ottimale, eseguire la versione più recente di Windows e acconsentire esplicitamente alle modifiche più recenti del sistema operativo aggiungendo un file app.manifest in un'applicazione di test e annullando il commento del codice seguente:
<!-- Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
Navigazione migliorata tramite tastiera
- Quando un controllo ComboBox ha la proprietà DropDownStyle impostata su ComboBoxStyle.DropDownList ed è il primo controllo nell'ordine di tabulazione del modulo, ora visualizza un rettangolo di messa a fuoco quando il modulo principale viene aperto tramite tastiera. Prima di questa modifica, lo stato attivo della tastiera era su questo controllo, ma non veniva visualizzato un indicatore di focus.
Supporto migliorato dell'Assistente Vocale
Il controllo MonthCalendar ha aggiunto il supporto per le tecnologie assistive, consentendo l'accesso al controllo, inclusa la possibilità per l'Assistente vocale di leggere il valore del controllo, cosa che in precedenza non era possibile.
Il controllo CheckedListBox invia una notifica all'Assistente vocale quando è stata modificata una proprietà CheckBox.CheckState. In precedenza, l'Assistente vocale non riceveva notifiche e di conseguenza gli utenti non sarebbero stati informati che la proprietà CheckState era stata aggiornata.
Il controllo LinkLabel ha modificato il modo in cui notifica all'Assistente vocale del testo nel controllo. In precedenza, il Narratore annunciava questo testo due volte e leggeva i simboli "&" come testo reale anche se non sono visibili a un utente. Il testo duplicato è stato rimosso dagli annunci di Narrator, così come i simboli "&" non necessari.
I tipi di controllo DataGridViewCell ora segnalano correttamente lo stato di sola lettura al Narratore e ad altre tecnologie assistive.
Narrator è ora in grado di leggere il menu di sistema delle finestre secondarie nelle applicazioni [Multiple-Document Interface]~/docs/framework/winforms/advanced/multiple-document-interface-mdi-applications.md).
L'Assistente vocale è ora in grado di leggere i controlli ToolStripMenuItem con una proprietà ToolStripItem.Enabled impostata su false. In precedenza, l'Assistente vocale non era in grado di focalizzarsi sugli elementi di menu disattivati per leggerne il contenuto.
Nome | Valore |
---|---|
Ambito | Maggiore |
Versione | 4.8 |
Digitare | Reindirizzamento |
API interessate
- ToolStripDropDownButton.CreateAccessibilityInstance()
- DomainUpDown.DomainUpDownAccessibleObject.Name
- MonthCalendar.AccessibilityObject
Windows Presentation Foundation (WPF)
Miglioramenti dell'accessibilità in WPF
Dettagli
miglioramenti al contrasto elevato
- Lo stato attivo per il controllo Expander è ora visibile. Nelle versioni precedenti di .NET Framework, non era.
- Il testo nei controlli CheckBox e RadioButton quando sono selezionati è ora più facile da vedere rispetto alle versioni precedenti di .NET Framework.
- Il bordo di un ComboBox disabilitato è ora lo stesso colore del testo disabilitato. Nelle versioni precedenti di .NET Framework, non era.
- I pulsanti disabilitati e messi a fuoco ora utilizzano il colore corretto del tema. Nelle versioni precedenti di .NET Framework, non lo erano.
- Il pulsante a discesa è ora visibile quando lo stile di un controllo ComboBox è impostato su ToolBar.ComboBoxStyleKey. Nelle versioni precedenti di .NET Framework, non era.
- La freccia dell'indicatore di ordinamento in un controllo DataGrid ora utilizza i colori del tema. Nelle versioni precedenti di .NET Framework, non era presente.
- Lo stile del collegamento ipertestuale predefinito ora cambia al colore del tema corretto al passaggio del mouse. Nelle versioni precedenti di .NET Framework, non lo faceva.
- Il focus della tastiera sui pulsanti di opzione è ora visibile. Nelle versioni precedenti di .NET Framework, non era.
- La colonna della casella di controllo del controllo DataGrid utilizza ora i colori previsti per il feedback del focus della tastiera. Nelle versioni precedenti di .NET Framework, ciò non accadeva.
- I segnali visivi del focus della tastiera sono ora visibili sui controlli ComboBox e ListBox. Nelle versioni precedenti di .NET Framework, non era.
miglioramenti nell'interazione con i lettori di schermo
- Expander i controlli vengono ora annunciati correttamente come gruppi (espandi/riduci) dai lettori di schermo.
- DataGridCell controllo viene ora annunciato correttamente come cella della griglia dati (localizzata) dai lettori di schermo.
- Gli screen reader annunceranno ora il nome di un ComboBoxmodificabile.
- I controlli PasswordBox non vengono più annunciati come "nessun elemento nella visualizzazione" dai screen reader.
Supporto LiveRegion
Gli strumenti di lettura dello schermo, come Assistente vocale, aiutano le persone a comprendere l'interfaccia utente di un'applicazione, solitamente descrivendo l'elemento dell'interfaccia utente attualmente in evidenza. Tuttavia, se un elemento dell'interfaccia utente cambia da qualche parte nella schermata e non ha lo stato attivo, l'utente potrebbe non essere informato e perdere informazioni importanti. LiveRegions sono concepite per risolvere questo problema. Uno sviluppatore può usarli per informare l'utilità per la lettura dello schermo o qualsiasi altro client di automazione interfaccia utente che è stata apportata una modifica importante a un elemento dell'interfaccia utente. L'utilità per la lettura dello schermo può quindi decidere come e quando informare l'utente di questa modifica. La proprietà LiveSetting consente anche all'utilità per la lettura dello schermo di sapere quanto sia importante informare l'utente della modifica apportata all'interfaccia utente.
Suggerimento
Come acconsentire esplicitamente o rifiutare queste modifiche
Affinché l'applicazione possa trarre vantaggio da queste modifiche, deve essere eseguita in .NET Framework 4.7.1 o versione successiva. L'applicazione può trarre vantaggio da queste modifiche in uno dei modi seguenti:
Destinazione .NET Framework 4.7.1. Questo è l'approccio consigliato. Queste modifiche all'accessibilità sono abilitate per impostazione predefinita nelle applicazioni WPF destinate a .NET Framework 4.7.1 o versioni successive.
Disattiva i comportamenti di accessibilità legacy aggiungendo il seguente AppContext Switch nella sezione
<runtime>
del file di configurazione dell'applicazione e impostandolo sufalse
, come mostrato nell'esempio seguente.<?xml version="1.0" encoding="utf-8"?> <configuration> <startup> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7"/> </startup> <runtime> <!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false' --> <AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false" /> </runtime> </configuration>
Le applicazioni destinate a .NET Framework 4.7.1 o versioni successive e vogliono mantenere il comportamento di accessibilità legacy possono acconsentire esplicitamente all'uso delle funzionalità di accessibilità legacy impostando in modo esplicito l'opzione AppContext su true
.
Per una panoramica dell'automazione dell'interfaccia utente, vedere Panoramica dell'automazione dell'interfaccia utente.
Nome | Valore |
---|---|
Ambito | Maggiore |
Versione | 4.7.1 |
Digitare | Reindirizzamento |
API interessate
- AutomationElementIdentifiers.LiveSettingProperty
- AutomationElementIdentifiers.LiveRegionChangedEvent
- System.Windows.Automation.AutomationLiveSetting
- AutomationProperties.LiveSettingProperty
- AutomationProperties.SetLiveSetting(DependencyObject, AutomationLiveSetting)
- AutomationProperties.GetLiveSetting(DependencyObject)
- AutomationPeer.GetLiveSettingCore()
Evento della SelectionChanged del Selector e proprietà della SelectedValue
Dettagli
A partire da .NET Framework 4.7.1, un Selector aggiorna sempre il valore della relativa proprietà SelectedValue prima di generare l'evento SelectionChanged quando cambia la selezione. In questo modo la proprietà SelectedValue è coerente con le altre proprietà di selezione (SelectedItem e SelectedIndex), che vengono aggiornate prima di generare l'evento.
In .NET Framework 4.7 e versioni precedenti, l'aggiornamento a SelectedValue si è verificato prima dell'evento nella maggior parte dei casi, ma si è verificato dopo l'evento se la modifica della selezione è stata causata dalla modifica della proprietà SelectedValue.
Suggerimento
Le app destinate a .NET Framework 4.7.1 o versioni successive possono rifiutare esplicitamente questa modifica e usare il comportamento legacy aggiungendo quanto segue alla sezione <runtime>
del file di configurazione dell'applicazione:
<runtime>
<AppContextSwitchOverrides
value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=true" />
</runtime>
Le app destinate a .NET Framework 4.7 o versioni precedenti ma in esecuzione in .NET Framework 4.7.1 o versioni successive possono abilitare il nuovo comportamento aggiungendo la riga seguente alla sezione <runtime>
del file di configurazione dell'applicazione:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=false" />
</runtime>
Nome | Valore |
---|---|
Ambito | Minore |
Versione | 4.7.1 |
Digitare | Reindirizzamento |
API interessate
Evento TabControl SelectionChanged e proprietà SelectedContent
Dettagli
A partire da .NET Framework 4.7.1, un TabControl aggiorna il valore della relativa proprietà SelectedContent prima di generare l'evento SelectionChanged, quando cambia la selezione. In .NET Framework 4.7 e versioni precedenti l'aggiornamento a SelectedContent si è verificato dopo l'evento.
Suggerimento
Le app destinate a .NET Framework 4.7.1 o versioni successive possono rifiutare esplicitamente questa modifica e usare il comportamento legacy aggiungendo quanto segue alla sezione <runtime>
del file di configurazione dell'applicazione:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=true" />
</runtime>
Le app destinate a .NET Framework 4.7 o versioni precedenti ma in esecuzione in .NET Framework 4.7.1 o versioni successive possono abilitare il nuovo comportamento aggiungendo la riga seguente alla sezione <runtime>
del file di configurazione dell'applicazione:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=false" />
</runtime>
Nome | Valore |
---|---|
Ambito | Minore |
Versione | 4.7.1 |
Tipo | Reindirizzamento |
API interessate
L'algoritmo hash predefinito per WPF PackageDigitalSignatureManager è ora SHA256
Dettagli
Il System.IO.Packaging.PackageDigitalSignatureManager
fornisce funzionalità per le firme digitali in relazione ai pacchetti WPF. In .NET Framework 4.7 e versioni precedenti, l'algoritmo predefinito (PackageDigitalSignatureManager.DefaultHashAlgorithm) usato per firmare parti di un pacchetto era SHA1. A causa di recenti problemi di sicurezza con SHA1, questa impostazione predefinita è stata modificata in SHA256 a partire da .NET Framework 4.7.1. Questa modifica influisce su tutte le firme dei pacchetti, inclusi i documenti XPS.
Suggerimento
Uno sviluppatore che desidera utilizzare questa modifica mentre si rivolge a una versione del framework inferiore a .NET Framework 4.7.1, oppure uno sviluppatore che richiede la funzionalità precedente mentre si rivolge a .NET Framework 4.7.1 o successivi, può impostare il seguente flag AppContext in modo appropriato. Il valore true comporterà l'uso di SHA1 come algoritmo predefinito; false restituisce SHA256.
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.MS.Internal.UseSha1AsDefaultHashAlgorithmForDigitalSignatures=true"/>
</runtime>
</configuration>
Nome | Valore |
---|---|
Portata | Edge |
Versione | 4.7.1 |
Digitare | Reindirizzamento |
API interessate
Windows Workflow Foundation (WF)
Miglioramenti dell'accessibilità nella finestra di progettazione del flusso di lavoro di Windows Workflow Foundation (WF)
Dettagli
La finestra di progettazione del flusso di lavoro di Windows Workflow Foundation (WF) migliora l'interoperabilità con le tecnologie di accessibilità. Questi miglioramenti includono le modifiche seguenti:
- L'ordine di tabulazioni viene modificato da sinistra a destra e dall'alto verso il basso in alcuni controlli:
- Finestra di avvio della correlazione per impostare i dati della correlazione per l'attività InitializeCorrelation
- Finestra di definizione del contenuto per le attività di Receive, Send, SendReplye ReceiveReply
- Sono disponibili altre funzioni tramite la tastiera:
- Quando si modificano le proprietà di un'attività, i gruppi di proprietà possono essere ridotti tramite tastiera la prima volta che vengono messi a fuoco.
- Le icone di avviso sono ora accessibili tramite tastiera.
- Il pulsante Altre proprietà nella finestra Proprietà è ora accessibile tramite tastiera.
- Gli utenti della tastiera possono ora accedere agli elementi di intestazione nei riquadri Argomenti e Variabili del Workflow Designer.
- Maggiore visibilità degli elementi con stato attivo, ad esempio quando:
- Aggiunta di righe alle griglie di dati usate da Progettazione flussi di lavoro e ActivityDesigner.
- Tabulazione dei campi nelle attività di ReceiveReply e SendReply.
- Impostazione dei valori predefiniti per variabili o argomenti
- I lettori di schermo ora possono riconoscere correttamente:
- Punti di interruzione impostati nella finestra di progettazione del flusso di lavoro.
- Attività FlowSwitch<T>, FlowDecisione CorrelationScope.
- Contenuto dell'attività Receive.
- Tipo di destinazione per l'attività InvokeMethod.
- La casella combinata "Eccezione" e la sezione "Finalmente" nell'attività TryCatch.
- La casella combinata Tipo di messaggio, il separatore nella finestra Aggiungi inizializzatori di correlazione, la finestra Definizione contenuto e la finestra Definizione CorrelatesOn nelle attività di messaggistica (Receive, Send, SendReplye ReceiveReply).
- Le transizioni della macchina a stati e le destinazioni delle transizioni.
- Annotazioni e connettori sulle attività di FlowDecision.
- Menu contestuali (clic destro) per le attività.
- Editor dei valori delle proprietà, il pulsante Cancella ricerca, i pulsanti di ordinamento per categoria e per ordine alfabetico e la finestra di dialogo dell'Editor espressioni nella griglia delle proprietà.
- Percentuale di zoom nella progettazione dei flussi di lavoro.
- Il separatore delle attività di Parallel e Pick.
- Attività InvokeDelegate.
- Finestra Selezione Tipi per le attività del dizionario (
Microsoft.Activities.AddToDictionary<TKey,TValue>
,Microsoft.Activities.RemoveFromDictionary<TKey,TValue>
e così via). - Finestra Sfoglia e Seleziona tipo .NET.
- Percorsi di navigazione nel Designer di flussi di lavoro.
- Gli utenti che scelgono temi a contrasto elevato noteranno molti miglioramenti nella visibilità del Progettazione flussi di lavoro e dei suoi controlli, come rapporti di contrasto migliori tra gli elementi e caselle di selezione più evidenti utilizzate per evidenziare gli elementi attivi.
Suggerimento
Se disponi di un'applicazione con un progettista di flussi di lavoro riospitato, la tua applicazione può beneficiare di queste modifiche eseguendo una delle seguenti azioni:
- Ricompilare l'applicazione in modo che sia destinato a .NET Framework 4.7.1. Queste modifiche all'accessibilità sono abilitate per impostazione predefinita.
- Se l'applicazione è destinata al .NET Framework 4.7 o versioni precedenti ma è in esecuzione sul .NET Framework 4.7.1, è possibile disattivare questi comportamenti di accessibilità legacy aggiungendo il seguente switch AppContext alla sezione
<runtime>
del file app.config e impostarlo sufalse
, come illustrato nell'esempio seguente.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7"/>
</startup>
<runtime>
<!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false -->
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false" />
</runtime>
</configuration>
Le applicazioni destinate a .NET Framework 4.7.1 o versioni successive e vogliono mantenere il comportamento di accessibilità legacy possono acconsentire esplicitamente all'uso delle funzionalità di accessibilità legacy impostando in modo esplicito questa opzione AppContext su true
.
Nome | Valore |
---|---|
Ambito | Minore |
Versione | 4.7.1 |
Digitare | Reindirizzamento |
.NET Framework 4.7.2
Nucleo
Consenti caratteri di controllo bidirezionali Unicode negli URI
Dettagli
Unicode specifica diversi caratteri di controllo speciali utilizzati per specificare l'orientamento del testo. Nelle versioni precedenti di .NET Framework questi caratteri sono stati rimossi erroneamente da tutti gli URI anche se erano presenti nel formato con codifica percentuale. Per seguire meglio RFC 3987, ora sono consentiti questi caratteri negli URI. Quando vengono trovati non codificati in un URI, sono percentualmente codificati. Quando vengono trovati codificati in percentuale, sono lasciati come as-is.
Suggerimento
Per le applicazioni destinate a versioni di .NET Framework a partire dalla versione 4.7.2, il supporto per i caratteri bidirezionali Unicode è abilitato per impostazione predefinita. Se questa modifica è indesiderata, è possibile disabilitarla aggiungendo il seguente switch AppContextSwitchOverrides nella sezione <runtime>
del file di configurazione dell'applicazione.
<runtime>
<AppContextSwitchOverrides value="Switch.System.Uri.DontKeepUnicodeBidiFormattingCharacters=true" />
</runtime>
Per le applicazioni destinate a versioni precedenti di .NET Framework, ma in esecuzione in versioni a partire da .NET Framework 4.7.2, il supporto per i caratteri bidirezionali Unicode è disabilitato per impostazione predefinita. È possibile abilitarla aggiungendo l'interruttore AppContextSwitchOverrides alla sezione <runtime>
del file di configurazione dell'applicazione:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Uri.DontKeepUnicodeBidiFormattingCharacters=false" />
</runtime>
Nome | Valore |
---|---|
Ambito | Minore |
Versione | 4.7.2 |
Digitare | Reindirizzamento |
API interessate
DeflateStream usa API native per la decompressione
Dettagli
A partire da .NET Framework 4.7.2, l'implementazione della decompressione nella classe T:System.IO.Compression.DeflateStream
è stata modificata in modo da usare le API di Windows native per impostazione predefinita. In genere, ciò comporta un miglioramento sostanziale delle prestazioni. Tutte le applicazioni .NET destinate a .NET Framework versione 4.7.2 o successiva usano l'implementazione nativa. Questa modifica può comportare alcune differenze nel comportamento, tra cui:
- I messaggi di eccezione possono essere diversi. Tuttavia, il tipo di eccezione generata rimane invariato.
- Alcune situazioni speciali, ad esempio la memoria insufficiente per completare un'operazione, possono essere gestite in modo diverso.
- Esistono differenze note per l'analisi dell'header gzip (nota: è interessato solo il set
GZipStream
per la decompressione): - Le eccezioni durante l'analisi delle intestazioni non valide possono essere lanciate in momenti diversi.
- L'implementazione nativa impone che i valori per alcuni flag riservati all'interno dell'intestazione gzip (ad esempio FLG) siano impostati in base alla specifica, il che può causare il lancio di un'eccezione dove in precedenza i valori non validi venivano ignorati.
Suggerimento
Se la decompressione con API native influisce negativamente sul comportamento dell'app, puoi rifiutare esplicitamente questa funzionalità aggiungendo l'opzione Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression
alla sezione runtime
del file di app.config e impostandola su true
:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression=true" />
</runtime>
</configuration>
Nome | Valore |
---|---|
Ambito | Minore |
Versione | 4.7.2 |
Digitare | Reindirizzamento |
API interessate
Verificare che System.Uri usi un set di caratteri riservati coerente
Dettagli
In System.Uri, alcuni caratteri codificati in percentuale che a volte venivano decodificati ora rimangono costantemente codificati. Ciò si verifica tra le proprietà e i metodi che accedono ai componenti path, query, fragment o userinfo dell'URI. Il comportamento cambierà solo quando sono vere entrambe le condizioni seguenti:
- L'URI contiene il formato codificato di uno dei caratteri riservati seguenti:
:
,'
,(
,)
,!
o*
. - L'URI contiene un carattere Unicode o un carattere non riservato codificato. Se entrambi i valori precedenti sono true, i caratteri riservati codificati vengono lasciati codificati. Nelle versioni precedenti di .NET Framework vengono decodificate.
Suggerimento
Per le applicazioni destinate a versioni di .NET Framework a partire dalla versione 4.7.2, il nuovo comportamento di decodifica è abilitato per impostazione predefinita. Se questa modifica è indesiderata, è possibile disabilitarla aggiungendo il seguente interruttore AppContextSwitchOverrides nella sezione <runtime>
del file di configurazione dell'applicazione.
<runtime>
<AppContextSwitchOverrides value="Switch.System.Uri.DontEnableStrictRFC3986ReservedCharacterSets=true" />
</runtime>
Per le applicazioni destinate a versioni precedenti di .NET Framework, ma in esecuzione in versioni a partire da .NET Framework 4.7.2, il nuovo comportamento di decodifica è disabilitato per impostazione predefinita. È possibile abilitarla aggiungendo il seguente interruttore AppContextSwitchOverrides alla sezione <runtime>
del file di configurazione dell'applicazione:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Uri.DontEnableStrictRFC3986ReservedCharacterSets=false" />
</runtime>
Nome | Valore |
---|---|
Ambito | Minore |
Versione | 4.7.2 |
Digitare | Ritargetizzazione |
API interessate
Resgen rifiuta di caricare il contenuto dal Web
Dettagli
I file resx possono contenere input in formato binario. Se si cerca di utilizzare resgen per caricare un file scaricato da un percorso non attendibile, per impostazione predefinita non riuscirà a caricare l'input.
Suggerimento
Gli utenti Resgen che richiedono il caricamento di input in formato binario da percorsi non attendibili possono rimuovere il contrassegno del Web dal file di input o applicare l'eccezione di esclusione. Aggiungere l'impostazione del Registro di sistema seguente per applicare l'eccezione di esclusione a livello di computer: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\SDK] "AllowProcessOfUntrustedResourceFiles"="true"
Nome | Valore |
---|---|
Ambito | Edge |
Versione | 4.7.2 |
Digitare | Reindirizzamento |
Le stack trace ottenute utilizzando file PDB portatili ora includono informazioni sul file di origine e sulla riga, laddove richiesto.
Dettagli
A partire da .NET Framework 4.7.2, le tracce dello stack ottenute quando si usano file PDB portabili includono informazioni sul file di origine e sulla riga su richiesta. Nelle versioni precedenti a .NET Framework 4.7.2, le informazioni sul file di origine e sulla riga non sarebbero disponibili quando si usano PDB portabili anche se richiesto in modo esplicito.
Suggerimento
Per le applicazioni destinate a .NET Framework 4.7.2, è possibile escludere il file di origine e le informazioni sulla riga quando si usano PDB portatili se non è desiderabile, aggiungendo quanto segue alla sezione <runtime>
del file app.config
:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Diagnostics.IgnorePortablePDBsInStackTraces=true" />
</runtime>
Per le applicazioni destinate a versioni precedenti di .NET Framework, ma eseguite su .NET Framework 4.7.2 o versioni successive, è possibile optare per l'inclusione del file di origine e delle informazioni sulla riga quando si utilizzano i PDB portatili, aggiungendo quanto segue alla sezione <runtime>
del file app.config
:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Diagnostics.IgnorePortablePDBsInStackTraces=false" />
</runtime>
Nome | Valore |
---|---|
Ambito | Edge |
Versione | 4.7.2 |
Digitare | Reindirizzamento |
API interessate
Windows Forms
Miglioramenti dell'accessibilità nei controlli Windows Form per .NET 4.7.2
Dettagli
Windows Form Framework sta migliorando il funzionamento con le tecnologie di accessibilità per supportare meglio i clienti di Windows Form. Di seguito sono riportate le modifiche seguenti:
- Modifiche per migliorare la visualizzazione durante la modalità a contrasto elevato.
- Modifiche per migliorare lo spostamento tramite tastiera nei controlli DataGridView e MenuStrip.
- Modifiche all'interazione con l'Assistente vocale.
Suggerimento
Come acconsentire esplicitamente o rifiutare queste modifiche Affinché l'applicazione possa trarre vantaggio da queste modifiche, deve essere eseguita in .NET Framework 4.7.2 o versione successiva. L'applicazione può trarre vantaggio da queste modifiche in uno dei modi seguenti:
- Viene ricompilato per usare .NET Framework 4.7.2. Queste modifiche all'accessibilità sono abilitate per impostazione predefinita nelle applicazioni Windows Form destinate a .NET Framework 4.7.2 o versioni successive.
- È destinato a .NET Framework 4.7.1 o versione precedente ed esclude esplicitamente i comportamenti di accessibilità legacy aggiungendo la seguente opzione AppContext alla sezione
<runtime>
del file di configurazione dell'app e impostandola sufalse
, come illustrato nell'esempio seguente.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7"/>
</startup>
<runtime>
<!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false -->
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false" />
</runtime>
</configuration>
Si noti che per acconsentire esplicitamente alle funzionalità di accessibilità aggiunte in .NET Framework 4.7.2, è anche necessario acconsentire esplicitamente alle funzionalità di accessibilità di .NET Framework 4.7.1. Le applicazioni destinate a .NET Framework 4.7.2 o versioni successive e vogliono mantenere il comportamento di accessibilità legacy possono acconsentire esplicitamente all'uso delle funzionalità di accessibilità legacy impostando in modo esplicito questa opzione AppContext su true
.
Uso dei colori definiti dal sistema operativo nei temi a contrasto elevato
- La freccia a discesa del ToolStripDropDownButton ora utilizza i colori specificati dal sistema operativo nel tema ad alto contrasto.
- Button, i controlli RadioButton e CheckBox con FlatStyle impostato su FlatStyle.Flat o FlatStyle.Popup ora usano colori definiti dal sistema operativo nel tema a contrasto elevato quando selezionati. In precedenza, i colori di testo e di sfondo non erano in contrasto e erano difficili da leggere.
- I controlli contenuti in un GroupBox con la relativa proprietà Enabled impostata su
false
useranno ora colori definiti dal sistema operativo nel tema a contrasto elevato. - I controlli ToolStripButton, ToolStripComboBoxe ToolStripDropDownButton hanno un maggiore rapporto di contrasto della luminosità in modalità contrasto elevato.
- DataGridViewLinkCell userà per impostazione predefinita i colori definiti dal sistema operativo in modalità contrasto elevato per la proprietà DataGridViewLinkCell.LinkColor. NOTA: Windows 10 ha modificato i valori per alcuni colori di sistema a contrasto elevato. Windows Form Framework si basa sul framework Win32. Per un'esperienza ottimale, eseguire la versione più recente di Windows e acconsentire esplicitamente alle modifiche più recenti del sistema operativo aggiungendo un file app.manifest in un'applicazione di test e annullando il commento del codice seguente:
<!-- Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
Supporto migliorato per Assistente vocale
- Il narratore ora annuncia il valore della proprietà ToolStripMenuItem.ShortcutKeys quando proclama il testo di un ToolStripMenuItem.
- L'Assistente vocale indica ora quando una ToolStripMenuItem ha la proprietà Enabled impostata su
false
. - L'Assistente vocale fornisce ora commenti e suggerimenti sullo stato di una casella di controllo quando la proprietà ListView.CheckBoxes è impostata su
true
. - L'ordine di messa a fuoco della Modalità scansione dell'Assistente vocale è ora coerente con l'ordine visivo dei controlli nella finestra di dialogo del download ClickOnce.
Migliorato supporto dell'accessibilità per DataGridView
- È ora possibile ordinare le righe in un DataGridView usando la tastiera. Ora un utente può usare il tasto F3 per ordinare in base alla colonna corrente.
- Quando la DataGridView.SelectionMode è impostata su DataGridViewSelectionMode.FullRowSelect, l'intestazione della colonna cambierà colore per indicare la colonna corrente mentre l'utente passa attraverso le celle della riga corrente.
- La proprietà DataGridViewCell.DataGridViewCellAccessibleObject.Parent restituisce ora il controllo padre corretto.
Indici Visivi Migliorati
- I controlli RadioButton e CheckBox con una proprietà Text vuota ora visualizzeranno un indicatore di focus quando sono messi a fuoco.
Supporto Migliorato della Griglia delle Proprietà
Gli elementi figlio del controllo PropertyGrid restituiscono ora un
true
per la proprietà IsReadOnlyProperty solo quando è abilitato un elemento PropertyGrid.I sottoelementi del controllo PropertyGrid restituiscono un
Navigazione migliorata tramite tastierafalse
per la proprietà IsEnabledProperty solo quando un elemento PropertyGrid può essere modificato dall'utente. Per una panoramica dell'automazione interfaccia utente, vedere Panoramica automazione interfaccia utente.ToolStripButton ora consente lo stato attivo quando è contenuto in un ToolStripPanel con la proprietà TabStop impostata su
true
.
Nome | Valore |
---|---|
Ambito | Maggiore |
Versione | 4.7.2 |
Digitare | Reindirizzamento |
La proprietà ContextMenuStrip.SourceControl contiene un controllo valido nel caso di ToolStripMenuItems annidati.
Dettagli
In .NET Framework 4.7.1 e versioni precedenti la proprietà ContextMenuStrip.SourceControl restituisce erroneamente Null quando l'utente apre il menu dai controlli ToolStripMenuItem annidati. In .NET Framework 4.7.2 e versioni successive, SourceControl proprietà è sempre impostata sul controllo del codice sorgente effettivo.
Suggerimento
Come acconsentire esplicitamente o rifiutare queste modifiche Affinché un'applicazione possa trarre vantaggio da queste modifiche, deve essere eseguita in .NET Framework 4.7.2 o versione successiva. L'applicazione può trarre vantaggio da queste modifiche in uno dei modi seguenti:
- È destinato al software .NET Framework 4.7.2. Questa modifica è abilitata per impostazione predefinita nelle applicazioni Windows Form destinate a .NET Framework 4.7.2 o versione successiva.
- È destinato a .NET Framework 4.7.1 o a una versione precedente e rifiuta esplicitamente i comportamenti di accessibilità legacy aggiungendo il seguente 'opzione AppContext alla sezione
<runtime>
del file app.config e impostandola sufalse
, come illustrato nell'esempio seguente.
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue=false"/>
</runtime>
Le applicazioni destinate a .NET Framework 4.7.2 o versioni successive e vogliono mantenere il comportamento legacy possono acconsentire esplicitamente all'uso del valore del controllo del codice sorgente legacy impostando in modo esplicito questa opzione AppContext su true
.
Nome | Valore |
---|---|
Scopo | Microsoft Edge |
Versione | 4.7.2 |
Digitare | Reindirizzamento |
API interessate
Il metodo PrivateFontCollection.AddFontFile rilascia le risorse font
Dettagli
In .NET Framework 4.7.1 e versioni precedenti, la classe System.Drawing.Text.PrivateFontCollection non rilascia le risorse del tipo di carattere GDI+ dopo che la PrivateFontCollection viene eliminata per gli oggetti Font aggiunti a questa raccolta usando il metodo AddFontFile(String). In .NET Framework 4.7.2 e versioni successive Dispose rilascia i tipi di carattere GDI+ aggiunti alla raccolta come file.
Suggerimento
Come acconsentire esplicitamente o rifiutare queste modifiche Affinché un'applicazione possa trarre vantaggio da queste modifiche, deve essere eseguita in .NET Framework 4.7.2 o versione successiva. L'applicazione può trarre vantaggio da queste modifiche in uno dei modi seguenti:
- Viene ricompilato per usare .NET Framework 4.7.2. Questa modifica è abilitata per impostazione predefinita nelle applicazioni Windows Form destinate a .NET Framework 4.7.2 o versione successiva.
- È destinato al .NET Framework 4.7.1 o a una versione precedente ed esclude i comportamenti di accessibilità legacy aggiungendo la seguente opzione AppContext alla sezione
<runtime>
del file app.config e impostandola sufalse
, come illustrato nell'esempio seguente.
<runtime>
<AppContextSwitchOverrides value="Switch.System.Drawing.Text.DoNotRemoveGdiFontsResourcesFromFontCollection=false"/>
</runtime>
Le applicazioni destinate al .NET Framework 4.7.2 o versioni successive e che vogliono mantenere il comportamento legacy possono scegliere di non rilasciare le risorse dei tipi di carattere impostando questa opzione di AppContext su true
.
Nome | Valore |
---|---|
Ambito | Edge |
Versione | 4.7.2 |
Digitare | Reindirizzamento |
API interessate
Le azioni upbutton e downbutton del dominio WinForm sono ora sincronizzate
Dettagli
In .NET Framework 4.7.1 e nelle versioni precedenti, l'azione DomainUpDown.UpButton() sul controllo DomainUpDown viene ignorata quando è presente del testo nel controllo, e lo sviluppatore deve usare l'azione DomainUpDown.DownButton() sul controllo prima di usare l'azione DomainUpDown.UpButton(). A partire da .NET Framework 4.7.2, le azioni DomainUpDown.UpButton() e DomainUpDown.DownButton() funzionano in modo indipendente in questo scenario e rimangono sincronizzate.
Suggerimento
Affinché un'applicazione possa trarre vantaggio da queste modifiche, deve essere eseguita in .NET Framework 4.7.2 o versione successiva. L'applicazione può trarre vantaggio da queste modifiche in uno dei modi seguenti:
- Viene ricompilato per usare .NET Framework 4.7.2. Questa modifica è abilitata per impostazione predefinita nelle applicazioni Windows Form destinate a .NET Framework 4.7.2 o versione successiva.
- Rifiuta esplicitamente il comportamento di scorrimento legacy aggiungendo il seguente AppContext Switch alla sezione
<runtime>
del file di configurazione dell'app e impostandolo sufalse
, come illustrato nell'esempio seguente.
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling=false"/>
</runtime>
Nome | Valore |
---|---|
Ambito | Bordo |
Versione | 4.7.2 |
Digitare | Reindirizzamento |
API interessate
Windows Presentation Foundation (WPF)
Lo stato attivo della tastiera ora si sposta correttamente tra più livelli di hosting WinForms/WPF
Dettagli
Si consideri un'applicazione WPF che ospita un controllo WinForms che a sua volta ospita i controlli WPF. Gli utenti potrebbero non essere in grado di uscire dal livello WinForms se il primo o l'ultimo controllo in quel livello è il WPF System.Windows.Forms.Integration.ElementHost
. Questa modifica risolve questo problema e ora gli utenti sono in grado di navigare con il tasto tabulatore al di fuori del livello WinForms. Le applicazioni automatizzate che si basano sul fatto che lo stato attivo non esca mai dal livello WinForms potrebbero non funzionare più correttamente come previsto.
Suggerimento
Uno sviluppatore che desidera utilizzare questa modifica su una versione del framework inferiore a .NET 4.7.2 può impostare il seguente set di flag AppContext su false per attivare la modifica.
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false"/>
</runtime>
</configuration>
Le applicazioni WPF devono acconsentire esplicitamente a tutti i miglioramenti iniziali dell'accessibilità per ottenere i miglioramenti successivi. In altre parole, sia il commutatore Switch.UseLegacyAccessibilityFeatures
che il commutatore Switch.UseLegacyAccessibilityFeatures.2
devono essere impostati. Uno sviluppatore che richiede la funzionalità precedente mentre mira a .NET 4.7.2 o ad una versione successiva può impostare il seguente flag AppContext su true affinché la modifica venga disabilitata.
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures.2=true"/>
</runtime>
</configuration>
Nome | Valore |
---|---|
Ambito | Edge |
Versione | 4.7.2 |
Tipo | Reindirizzamento |
L'algoritmo hash predefinito per il compilatore di markup WPF è ora SHA256
Dettagli
WPF MarkupCompiler fornisce servizi di compilazione per i file di markup XAML. In .NET Framework 4.7.1 e versioni precedenti l'algoritmo hash predefinito usato per i checksum era SHA1. A causa di recenti problemi di sicurezza con SHA1, questa impostazione predefinita è stata modificata in SHA256 a partire da .NET Framework 4.7.2. Questa modifica influisce su tutta la generazione di checksum per i file di markup durante la compilazione.
Suggerimento
Uno sviluppatore che ha come destinazione .NET Framework 4.7.2 o versione successiva e vuole ripristinare il comportamento hash SHA1 deve impostare il flag AppContext seguente.
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Markup.DoNotUseSha256ForMarkupCompilerChecksumAlgorithm=true"/>
</runtime>
</configuration>
Uno sviluppatore che vuole utilizzare l'hash SHA256 e mira a una versione del framework inferiore a .NET 4.7.2 deve assicurarsi di impostare il flag AppContext seguente. Si noti che la versione installata di .NET Framework deve essere 4.7.2 o successiva.
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Markup.DoNotUseSha256ForMarkupCompilerChecksumAlgorithm=false"/>
</runtime>
</configuration>
Nome | Valore |
---|---|
Ambito | Trasparente |
Versione | 4.7.2 |
Tipo | Reindirizzamento |
La gestione dell'arresto di AppDomain WPF può ora chiamare Dispatcher.Invoke durante la pulizia di eventi deboli
Dettagli
In .NET Framework 4.7.1 e versioni precedenti, WPF potenzialmente crea un System.Windows.Threading.Dispatcher nel thread finalizzatore di .NET durante l'arresto di AppDomain. Questo problema è stato risolto in .NET Framework 4.7.2 e versioni successive, rendendo la pulizia degli eventi deboli compatibile con i thread. A causa di questo problema, WPF può chiamare Dispatcher.Invoke per completare il processo di pulizia. In alcune applicazioni, questa modifica nella tempistica del finalizzatore può causare eccezioni durante l'arresto di AppDomain o del processo. Questo comportamento si verifica in genere nelle applicazioni che non arrestano correttamente i dispatcher in esecuzione sui thread di lavoro prima dell'arresto del processo o di un AppDomain. Tali applicazioni devono occuparsi di gestire correttamente la durata dei dispatcher.
Suggerimento
In .NET Framework 4.7.2 e versioni successive, gli sviluppatori possono disabilitare questa correzione per alleviare (ma non eliminare) i problemi di temporizzazione che possono verificarsi a causa della modifica alla pulizia. Per disabilitare la modifica nella pulizia, usare il flag AppContext seguente.
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotInvokeInWeakEventTableShutdownListener=true"/>
</runtime>
</configuration>
Nome | Valore |
---|---|
Ambito | Bordo |
Versione | 4.7.2 |
Tipo | Reindirizzamento |
Modificare una chiave primaria in WPF quando si visualizzano dati ADO in uno scenario master/dettaglio.
Dettagli
Si supponga di avere una raccolta ADO di elementi di tipo Order
, con una relazione denominata "OrderDetails" correlata a una raccolta di elementi di tipo Detail
tramite la chiave primaria "OrderID". Nell'app WPF è possibile associare un controllo elenco ai dettagli per un determinato ordine:
<ListBox ItemsSource="{Binding Path=OrderDetails}" >
dove DataContext è un Order
. WPF ottiene il valore della proprietà OrderDetails
, ovvero un insieme D di tutti gli elementi Detail
i cui OrderID
corrispondono al OrderID
dell'elemento master. La modifica del comportamento si verifica quando si modifica la chiave primaria OrderID
dell'elemento master. ADO modifica automaticamente il OrderID
di ognuno dei record interessati nell'insieme Details (vale a dire quelli copiati nella raccolta D). Ma cosa succede a D?
- Comportamento precedente: la raccolta D viene svuotata. L'elemento master non genera una notifica di modifica per la proprietà
OrderDetails
. ListBox continua a usare la raccolta D, che ora è vuota. - Nuovo comportamento: la Raccolta D resta invariata. Ognuno dei relativi elementi genera una notifica di modifica per la proprietà
OrderID
. La ListBox continua a usare la raccolta D e visualizza i dettagli con il nuovoOrderID
. WPF implementa il nuovo comportamento creando una raccolta D in modo diverso: chiamando il metodo ADO DataRowView.CreateChildView(DataRelation, Boolean) con l'argomentofollowParent
impostato sutrue
.
Suggerimento
Un'app ottiene il nuovo comportamento usando l'opzione AppContext seguente.
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Data.DoNotUseFollowParentWhenBindingToADODataRelation=false"/>
</runtime>
</configuration>
Per impostazione predefinita, l'interruttore è impostato su true
(comportamento precedente) per le app destinate a .NET 4.7.1 o versioni precedenti, e su false
(nuovo comportamento) per le app destinate a .NET 4.7.2 o versioni successive.
Nome | Valore |
---|---|
Ambito | Minore |
Versione | 4.7.2 |
Digitare | Ritargetizzazione |
Il FocusVisual di WPF per "RadioButton" e "CheckBox" ora viene visualizzato correttamente quando i controlli non hanno contenuto.
Dettagli
In .NET Framework 4.7.1 e versioni precedenti, WPF System.Windows.Controls.CheckBox e System.Windows.Controls.RadioButton hanno visualizzazioni del focus incoerenti e, nei temi Classico e ad alta visibilità, visualizzazioni del focus non corrette. Questi problemi si verificano nei casi in cui i controlli non dispongono di alcun set di contenuto. Questo può rendere la transizione tra i temi confusa e difficile vedere l'indicatore visivo dello stato attivo. In .NET Framework 4.7.2, questi oggetti visivi sono ora più coerenti tra i temi e più facilmente visibili nei temi classici e a contrasto elevato.
Suggerimento
Uno sviluppatore che lavora con .NET Framework 4.7.2 che vuole ripristinare il comportamento in .NET 4.7.1 dovrà impostare il flag AppContext seguente.
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures.2=true;"/>
</runtime>
</configuration>
Uno sviluppatore che vuole usare questa modifica quando ha come destinazione una versione del framework inferiore a .NET 4.7.2 deve impostare i flag AppContext seguenti. Si noti che tutti i flag devono essere impostati in modo appropriato e la versione installata di .NET Framework deve essere 4.7.2 o successiva. Le applicazioni WPF sono necessarie per acconsentire esplicitamente a tutti i miglioramenti di accessibilità precedenti per ottenere i miglioramenti più recenti. A tale scopo, assicurarsi che gli interruttori 'Switch.UseLegacyAccessibilityFeatures' e 'Switch.UseLegacyAccessibilityFeatures.2' siano impostati su false.
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false;"/>
</runtime>
</configuration>
Nome | Valore |
---|---|
Ambito | Edge |
Versione | 4.7.2 |
Digitare | Reindirizzamento |
La selezione di testo WPF TextBox/PasswordBox non segue i colori di sistema
Dettagli
In .NET Framework 4.7.1 e versioni precedenti, WPF System.Windows.Controls.TextBox
e System.Windows.Controls.PasswordBox
potevano eseguire solo il rendering di una selezione di testo nello strato Adorner. In alcuni temi di sistema, questo ostruirebbe il testo, rendendo difficile la lettura. In .NET Framework 4.7.2 e versioni successive gli sviluppatori hanno la possibilità di abilitare uno schema di rendering della selezione non basato su Adorner che risolve questo problema.
Suggerimento
Uno sviluppatore che vuole utilizzare questa modifica deve impostare il flag AppContext seguente in modo appropriato. Per usare questa funzionalità, la versione di .NET Framework installata deve essere 4.7.2 o successiva. Per abilitare la selezione non basata su adorner, usare il flag AppContext seguente.
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Text.UseAdornerForTextboxSelectionRendering=false"/>
</runtime>
</configuration>
Nome | Valore |
---|---|
Ambito | Bordo |
Versione | 4.7.2 |
Digitare | Reindirizzamento |
Windows Workflow Foundation (WF)
Evitare ricorsioni infinite per IWorkflowInstanceManagement.TransactedCancel e IWorkflowInstanceManagement.TransactedTerminate
Dettagli
In alcune circostanze, quando si usano le API IWorkflowInstanceManagement.TransactedCancel o IWorkflowInstanceManagement.TransactedTerminate per annullare o terminare un'istanza del servizio del flusso di lavoro, l'istanza potrebbe riscontrare un overflow dello stack a causa di una ricorsione infinita quando il runtime Workflow
tenta di memorizzare l'istanza del servizio nel processo di elaborazione della richiesta. Il problema si verifica se l'istanza del flusso di lavoro è in uno stato in cui è in attesa che venga completata un'altra richiesta WCF in sospeso verso un altro servizio. Le operazioni TransactedCancel
e TransactedTerminate
creano elementi di lavoro messi in coda per l'istanza del servizio di workflow. Questi elementi di lavoro non vengono eseguiti come parte dell'elaborazione della richiesta di TransactedCancel/TransactedTerminate
. Poiché l'istanza del servizio del flusso di lavoro è occupata in attesa del completamento dell'altra richiesta WCF in sospeso, l'elemento di lavoro creato resta in coda. L'operazione di TransactedCancel/TransactedTerminate
viene completata e il controllo viene restituito al client. Quando la transazione associata all'operazione di TransactedCancel/TransactedTerminate
tenta di eseguire il commit, deve conservare lo stato dell'istanza del servizio di flusso di lavoro. Tuttavia, poiché è presente una richiesta WCF
in sospeso per l'istanza, il runtime del flusso di lavoro non può rendere persistente l'istanza del servizio flusso di lavoro e un ciclo di ricorsione infinito porta all'overflow dello stack. Poiché TransactedCancel
e TransactedTerminate
creano solo un elemento di lavoro in memoria, il fatto che esista una transazione non ha alcun effetto. Un rollback della transazione non elimina l'elemento di lavoro. Per risolvere questo problema, a partire da .NET Framework 4.7.2, è stato introdotto un AppSetting
che può essere aggiunto alla web.config/app.config
del servizio del flusso di lavoro che indica al servizio di ignorare le transazioni per TransactedCancel
e TransactedTerminate
. In questo modo la transazione può eseguire il commit senza attendere che l'istanza del flusso di lavoro venga mantenuta. L'AppSetting per questa funzionalità è denominato microsoft:WorkflowServices:IgnoreTransactionsForTransactedCancelAndTransactedTerminate
. Un valore di true
indica che la transazione deve essere ignorata, così da evitare l'overflow dello stack. Il valore predefinito di AppSetting è false
, quindi le istanze esistenti del servizio di flusso di lavoro non sono interessate.
Suggerimento
Se utilizzi AppFabric o un altro client IWorkflowInstanceManagement e riscontri un overflow dello stack nell'istanza del servizio di workflow quando cerchi di annullare o terminare un'istanza del workflow, puoi aggiungere quanto segue alla sezione <appSettings>
del file web.config/app.config per il servizio di workflow:
<add key="microsoft:WorkflowServices:IgnoreTransactionsForTransactedCancelAndTransactedTerminate" value="true"/>
Se non si riscontra il problema, non è necessario eseguire questa operazione.
Nome | Valore |
---|---|
Ambito | Edge |
Versione | 4.7.2 |
Digitare | Reindirizzamento |