Modifications de reciblage pour la migration vers .NET Framework 4.7.x

Cet article répertorie les problèmes de compatibilité des applications introduits dans .NET Framework 4.7, 4.7.1 et 4.7.2.

.NET Framework 4.7

ASP.NET

HttpRuntime.AppDomainAppPath lève une exception NullReferenceException

Détails

Dans .NET Framework 4.6.2, le runtime lève un T:System.NullReferenceException quand vous récupérez une valeur P:System.Web.HttpRuntime.AppDomainAppPath qui inclut des caractères null. Dans .NET Framework 4.6.1 et les versions antérieures, le runtime lève un T:System.ArgumentNullException.

Suggestion

Vous pouvez effectuer l’une ou l’autre des opérations suivantes pour répondre à ce changement :

• Gérer T:System.NullReferenceException si votre application s’exécute sur .NET Framework 4.6.2.
• Effectuer une mise à niveau vers .NET Framework 4.7, qui restaure le comportement précédent et lève un T:System.ArgumentNullException.

Nom	Valeur
Étendue	Edge
Version	4.6.2
Type	Reciblage

API affectées

• HttpRuntime.AppDomainAppPath

Restriction des demandes simultanées par session

Détails

Dans .NET Framework 4.6.2 et les versions antérieures, ASP.NET exécute les requêtes séquentiellement avec le même SessionId et émet toujours SessionId par le biais de cookies par défaut. Si une page met beaucoup de temps à répondre, le simple fait d’appuyer sur la touche F5 dans le navigateur dégrade considérablement les performances du serveur. Dans le correctif, nous avons ajouté un compteur pour effectuer le suivi des requêtes en file d’attente et arrêter les requêtes quand elles dépassent une limite spécifiée. La valeur par défaut est 50. Si la limite est atteinte, un avertissement est journalisé dans le journal des événements et une réponse HTTP 500 peut être enregistrée dans le journal IIS.

Suggestion

Pour restaurer l’ancien comportement, vous pouvez ajouter le paramètre suivant à votre fichier web.config pour désactiver le nouveau comportement.

<appSettings>
    <add key="aspnet:RequestQueueLimitPerSession" value="2147483647"/>
</appSettings>

Nom	Valeur
Étendue	Edge
Version	4,7
Type	Reciblage

Mise en réseau

La valeur par défaut de ServicePointManager.SecurityProtocol est SecurityProtocolType.System.Default

Détails

À partir des applications qui ciblent .NET Framework 4.7, la valeur par défaut de la propriété ServicePointManager.SecurityProtocol est SecurityProtocolType.SystemDefault. Ce changement permet aux API de réseau .NET Framework basées sur SslStream (comme FTP, HTTPS et SMTP) d’hériter des protocoles de sécurité par défaut du système d’exploitation au lieu d’utiliser des valeurs codées en dur définies par le .NET Framework. La valeur par défaut varie en fonction du système d’exploitation et des configurations personnalisées effectuées par l’administrateur système. Pour plus d’informations sur le protocole Schannel par défaut dans chaque version du système d’exploitation Windows, consultez Protocols in TLS/SSL (Schannel SSP).

Pour les applications qui ciblent une version antérieure de .NET Framework, la valeur par défaut de la propriété ServicePointManager.SecurityProtocol dépend de la version de .NET Framework ciblée. Pour plus d’informations, consultez la section Mise en réseau de la rubrique Modifications de reciblage pour la migration de .NET Framework 4.5.2 vers la version 4.6.

Suggestion

Ce changement affecte les applications qui ciblent .NET Framework 4.7 ou versions ultérieures. Si vous préférez utiliser un protocole défini, au lieu de vous appuyer sur la valeur par défaut du système, vous pouvez définir explicitement la valeur de la propriété ServicePointManager.SecurityProtocol. Si ce changement n’est pas souhaitable, vous pouvez choisir de l’annuler en ajoutant un paramètre de configuration à la section <runtime> du fichier de configuration de votre application. L’exemple suivant montre la section <runtime> et l’option d’annulation Switch.System.Net.DontEnableSystemDefaultTlsVersions :

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

Nom	Valeur
Étendue	Secondaire
Version	4,7
Type	Reciblage

API affectées

• ServicePointManager.SecurityProtocol

SslStream prend en charge les alertes TLS

Détails

Après l’échec d’une négociation TLS, un System.IO.IOException avec une exception System.ComponentModel.Win32Exception interne est levé par la première opération d’E/S de lecture/écriture. Le code System.ComponentModel.Win32Exception.NativeErrorCode de System.ComponentModel.Win32Exception peut être mappé avec l’alerte TLS provenant du tiers distant à l’aide de Codes d’erreur Schannel pour alertes TLS et SSL. Pour plus d’informations, consultez RFC 2246 : Section 7.2.2 Alertes relatives aux erreurs.
Dans .NET Framework 4.6.2 et les versions antérieures, le comportement est l’expiration du canal de transport (généralement une connexion TCP) pendant une opération de lecture ou d’écriture si l’autre partie n’est pas parvenue à négocier la connexion et l’a rejetée immédiatement après.

Suggestion

Les applications qui appellent des API d’E/S réseau comme Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32) doivent gérer IOException ou System.TimeoutException.
La fonctionnalité des alertes TLS est activée par défaut à compter de .NET Framework 4.7. Afin de préserver la compatibilité, cette fonctionnalité est désactivée pour les applications ciblant .NET Framework 4.0 à .NET Framework 4.6.2 qui s’exécutent sur un système .NET Framework 4.7 ou ultérieur.
L’API de configuration suivante est disponible pour activer ou désactiver la fonctionnalité pour les applications .NET Framework 4.6 et ultérieures s’exécutant sur .NET Framework 4.7 ou version ultérieure.

• Par programmation : Doit être la première action qu’effectue l’application, car ServicePointManager ne s’initialisera qu’une seule fois :

  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>
  

• Clé de Registre (machine globale) : Définissez la valeur sur false pour activer la fonctionnalité dans .NET Framework 4.6 à 4.6.2.

  Key: HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\AppContext\Switch.System.Net.DontEnableTlsAlerts
  - Type: String
  - Value: "true"
  

Nom	Valeur
Étendue	Edge
Version	4,7
Type	Reciblage

API affectées

• System.Net.Security.SslStream
• System.Net.WebRequest
• System.Net.HttpWebRequest
• System.Net.FtpWebRequest
• System.Net.Mail.SmtpClient
• System.Net.Http

Sécurité

CspParameters.ParentWindowHandle attend maintenant une valeur HWND

Détails

La valeur ParentWindowHandle, introduite dans .NET Framework 2.0, permet à une application d’inscrire une valeur de handle de fenêtre parente, pour que toute interface utilisateur nécessaire pour accéder à la clé (par exemple, une invite de code confidentiel ou une boîte de dialogue de consentement) s’ouvre sous la forme d’un enfant modal de la fenêtre spécifiée. À partir des applications qui ciblent .NET Framework 4.7, une application Windows Forms peut définir la propriété ParentWindowHandle avec du code semblable au suivant :

cspParameters.ParentWindowHandle = form.Handle;

Dans les versions précédentes du .NET Framework, la valeur devait être un System.IntPtr représentant un emplacement en mémoire où se trouvait la valeur HWND. La définition de la propriété sur form.Handle sous Windows 7 et versions antérieures n’avait aucun effet, mais sous Windows 8 et versions ultérieures, cela entraîne : « System.Security.Cryptography.CryptographicException : Le paramètre est incorrect. »

Suggestion

Les applications ciblant .NET Framework 4.7 ou ultérieur qui souhaitent inscrire une relation de fenêtre parente sont encouragées à utiliser la forme simplifiée :

cspParameters.ParentWindowHandle = form.Handle;

Les utilisateurs qui avaient identifié que la bonne valeur à passer était l’adresse d’un emplacement de la mémoire qui détenait la valeur form.Handle peuvent refuser ce changement de comportement en définissant le commutateur AppContext Switch.System.Security.Cryptography.DoNotAddrOfCspParentWindowHandle sur true :

• En définissant des commutateurs de compatibilité programmatiquement sur AppContext, comme expliqué ici.
• En ajoutant la ligne suivante à la section <runtime> du fichier app.config :

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

À l’inverse, les utilisateurs qui souhaitent adopter ce nouveau comportement sur le runtime .NET Framework 4.7 quand l’application se charge sur des versions antérieures du .NET Framework peuvent définir le commutateur AppContext sur false.

Nom	Valeur
Étendue	Secondaire
Version	4,7
Type	Reciblage

API affectées

• CspParameters.ParentWindowHandle

SslStream prend en charge les alertes TLS

Détails

Après l’échec d’une négociation TLS, un System.IO.IOException avec une exception System.ComponentModel.Win32Exception interne est levé par la première opération d’E/S de lecture/écriture. Le code System.ComponentModel.Win32Exception.NativeErrorCode de System.ComponentModel.Win32Exception peut être mappé avec l’alerte TLS provenant du tiers distant à l’aide de Codes d’erreur Schannel pour alertes TLS et SSL. Pour plus d’informations, consultez RFC 2246 : Section 7.2.2 Alertes relatives aux erreurs.
Dans .NET Framework 4.6.2 et les versions antérieures, le comportement est l’expiration du canal de transport (généralement une connexion TCP) pendant une opération de lecture ou d’écriture si l’autre partie n’est pas parvenue à négocier la connexion et l’a rejetée immédiatement après.

Suggestion

Les applications qui appellent des API d’E/S réseau comme Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32) doivent gérer IOException ou System.TimeoutException.
La fonctionnalité des alertes TLS est activée par défaut à compter de .NET Framework 4.7. Afin de préserver la compatibilité, cette fonctionnalité est désactivée pour les applications ciblant .NET Framework 4.0 à .NET Framework 4.6.2 qui s’exécutent sur un système .NET Framework 4.7 ou ultérieur.
L’API de configuration suivante est disponible pour activer ou désactiver la fonctionnalité pour les applications .NET Framework 4.6 et ultérieures s’exécutant sur .NET Framework 4.7 ou version ultérieure.

• Par programmation : Doit être la première action qu’effectue l’application, car ServicePointManager ne s’initialisera qu’une seule fois :

  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>
  

• Clé de Registre (machine globale) : Définissez la valeur sur false pour activer la fonctionnalité dans .NET Framework 4.6 à 4.6.2.

  Key: HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\AppContext\Switch.System.Net.DontEnableTlsAlerts
  - Type: String
  - Value: "true"
  

Nom	Valeur
Étendue	Edge
Version	4,7
Type	Reciblage

API affectées

• 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 sérialisation des caractères de contrôle avec DataContractJsonSerializer est désormais compatible avec ECMAScript V6 et V8

Détails

Dans .NET Framework 4.6.2 et versions antérieures, System.Runtime.Serialization.Json.DataContractJsonSerializer ne sérialisait pas certains caractères de contrôle spéciaux, comme \b, \f et \t, d’une manière compatible avec les normes ECMAScript V6 et V8. À partir de .NET Framework 4.7, la sérialisation de ces caractères de contrôle est compatible avec ECMAScript V6 et V8.

Suggestion

Pour les applications qui ciblent .NET. Framework 4.7, cette fonctionnalité est activée par défaut. Si ce comportement n’est pas souhaitable, vous pouvez désactiver cette fonctionnalité en ajoutant la ligne suivante à la section <runtime> du fichier app.config ou au fichier web.config :

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

Nom	Valeur
Étendue	Edge
Version	4,7
Type	Reciblage

API affectées

• DataContractJsonSerializer.WriteObject(Stream, Object)
• DataContractJsonSerializer.WriteObject(XmlDictionaryWriter, Object)
• DataContractJsonSerializer.WriteObject(XmlWriter, Object)

La sécurité des messages WCF peut désormais utiliser TLS 1.1 et TLS 1.2

Détails

À compter de .NET Framework 4.7, les clients peuvent configurer TLS 1.1 ou TLS 1.2 dans la sécurité des messages WCF en plus de SSL 3.0 et TLS 1.0 à l’aide des paramètres de configuration d’application.

Suggestion

Dans .NET Framework 4.7, la prise en charge de TLS 1.1 et de TLS 1.2 dans la sécurité des messages WCF est désactivée par défaut. Vous pouvez l’activer en ajoutant la ligne suivante à la section <runtime> du fichier app.config ou du fichier web.config :

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

Nom	Valeur
Étendue	Edge
Version	4,7
Type	Reciblage

Windows Presentation Foundation (WPF)

Les appels à System.Windows.Input.PenContext.Disable sur des systèmes tactiles peuvent lever une exception ArgumentException

Détails

Dans certaines circonstances, les appels à la méthode System.Windows.Intput.PenContext.Disable interne sur des systèmes tactiles peuvent lever une exception T:System.ArgumentException non gérée en raison de la réentrance.

Suggestion

Ce problème a été résolu dans le .NET Framework 4.7. Pour éviter cette exception, effectuez une mise à niveau avec une version du .NET Framework supérieure ou égale à 4.7.

Nom	Valeur
Étendue	Edge
Version	4.6.1
Type	Reciblage

NullReferenceException dans le code de gestion des exceptions à partir de ImageSourceConverter.ConvertFrom

Détails

Une erreur dans le code de gestion des exceptions ConvertFrom(ITypeDescriptorContext, CultureInfo, Object) a provoqué la levée d’une exception System.NullReferenceException incorrecte au lieu de l’exception prévue (System.IO.DirectoryNotFoundException ou System.IO.FileNotFoundException). Ce changement corrige cette erreur pour que la méthode lève la bonne exception.

Par défaut, toutes les applications ciblant .NET Framework 4.6.2 et antérieur continuent à lever System.NullReferenceException pour assurer la compatibilité. Les développeurs ciblant .NET Framework 4.7 et ultérieur devraient voir les bonnes exceptions.

Suggestion

Les développeurs qui ciblent le .NET Framework 4.7 ou ultérieur et qui préfèrent obtenir l’exception System.NullReferenceException peuvent ajouter/fusionner les éléments suivants dans le fichier App.config de leur application :

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Media.ImageSourceConverter.OverrideExceptionWithNullReferenceException=true"/>
</runtime>
</configuration>

Nom	Valeur
Étendue	Edge
Version	4,7
Type	Reciblage

API affectées

• ImageSourceConverter.ConvertFrom(ITypeDescriptorContext, CultureInfo, Object)

Allocation par Grid de l’espace aux colonnes * dans WPF

Détails

À compter de .NET Framework 4.7, WPF remplace l’algorithme utilisé par Grid pour allouer de l’espace aux colonnes *. Il en résulte un changement de la largeur réelle affectée aux colonnes * dans plusieurs cas :

• Lorsqu’une ou plusieurs colonnes * ont également une largeur minimale ou maximale qui remplace l’allocation proportionnelle pour cette colonne. (La largeur minimale peut dériver d’une déclaration MinWidth explicite, ou d’un minimum implicite obtenu à partir du contenu de la colonne. La largeur maximale ne peut être définie qu’explicitement, à partir d’une déclaration MaxWidth.)
• Quand une ou plusieurs colonnes * déclarent un très grand poids *, supérieur à 10^298.
• Quand les poids * sont suffisamment différents pour rencontrer une instabilité du calcul en virgule flottante (dépassement de capacité positif ou négatif, perte de précision).
• Lorsque l’arrondi de disposition est activé, et que la résolution d’affichage efficace en PPP est suffisamment élevée. Dans les deux premiers cas, les largeurs produites par le nouvel algorithme peuvent être considérablement différentes de celles générées par l’ancien algorithme ; dans le dernier cas, la différence sera au plus de un ou deux pixels.

Le nouvel algorithme résout plusieurs bogues présents dans l’ancien algorithme :

• L’allocation totale à des colonnes peut dépasser la largeur de la grille. Cela peut se produire lors de l’allocation d’espace pour une colonne dont la part proportionnelle est inférieure à sa taille minimale. L’algorithme alloue la taille minimale, ce qui réduit l’espace disponible pour les autres colonnes. S’il ne reste aucune colonne * à allouer, l’allocation totale est trop grande.

• L’allocation totale peut être inférieure à la largeur de la grille. C’est le double problème pour #1, survenant lors de l’affectation à une colonne dont la part proportionnelle est supérieure à sa taille maximale, sans colonnes * restantes pour combler.

• Deux colonnes * peuvent recevoir des allocations non proportionnelles à leurs poids *. Il s’agit d’une version atténuée de #1/2, survenant lors de l’allocation aux colonnes * A, B et C (dans cet ordre), où la part proportionnelle de B ne respecte pas la contrainte min (ou max). Comme ci-dessus, cela modifie l’espace disponible pour la colonne C, qui obtient une allocation proportionnelle inférieure (ou supérieure) à A.

• Les colonnes avec des poids extrêmement volumineux (> 10^298) sont traitées comme si elles avaient un poids de 10^298. Les différences proportionnelles entre elles (et entre les colonnes avec des poids légèrement inférieurs) ne sont pas respectées.

• Les colonnes avec des poids infinis ne sont pas gérées correctement. (Il est en fait impossible de définir un poids infini, mais il s’agit d’une restriction artificielle. Le code d’allocation essayait de le gérer, sans succès.)

• Plusieurs problèmes mineurs en évitant le dépassement de capacité positif ou négatif, la perte de précision et autres problèmes liés aux nombres à virgule flottante.

• Les ajustements d’arrondi de disposition sont incorrects à un niveau de PPP suffisamment élevé. Le nouvel algorithme produit des résultats qui répondent aux critères suivants :

  • La largeur réelle affectée à une colonne * n’est jamais inférieure à sa largeur minimale ni supérieure à sa largeur maximale.
  • Chaque colonne * qui n’a pas de largeur minimale ou maximale affectée reçoit une largeur proportionnelle à son poids *. Pour être exact, si deux colonnes sont déclarées avec les largeurs x* et y*, respectivement, et qu’aucune colonne ne reçoit sa largeur minimale ou maximale, les largeurs effectives v et w affectées aux colonnes respectent les mêmes proportions : v / w == x / y.
  • La largeur totale allouée aux *-colonnes proportionnelles est égale à l’espace disponible après allocation aux colonnes avec contraintes (les *-colonnes fixes, auto, et qui se voient allouer leur largeur minimale ou maximale). Elle peut avoir pour valeur zéro, par exemple si la somme des largeurs minimales dépasse la largeur disponible de Grid.
  • Toutes ces instructions doivent être interprétées en considérant la mise en page « idéale ». Lorsque l’arrondi de disposition est activé, la largeur réelle peut différer de la largeur idéale jusqu’à un pixel.

Suggestion

Par défaut, les applications qui ciblent les versions du .NET Framework à partir de .NET Framework 4.7 voient le nouvel algorithme, tandis que les applications qui ciblent .NET Framework 4.6.2 ou antérieur voient l’ancien algorithme.

Pour remplacer la valeur par défaut, utilisez les paramètres de configuration suivants :

<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true" />
</runtime>

La valeur true sélectionne l’ancien algorithme, et false le nouvel algorithme.

Nom	Valeur
Étendue	Secondaire
Version	4,7
Type	Reciblage

Pile tactile basée sur un pointeur WPF

Détails

Ce changement ajoute la possibilité d’activer une pile facultative tactile/de stylet WPF basée sur WM_POINTER. Les développeurs qui n’activent pas ceci explicitement ne devraient voir aucun changement de comportement tactile/du stylet dans WPF. Problèmes connus actuels avec la pile facultative tactile/de stylet basée sur WM_POINTER :

• Pas de prise en charge de l’écriture manuscrite en temps réel.
• Bien que les plug-ins pour l’écriture manuscrite et le stylet fonctionnent toujours, ils sont traités sur le thread d’interface utilisateur, ce qui peut entraîner une baisse des performances.
• Changements de comportement en raison de changements dans la promotion d’événements tactiles/de stylet en événements de souris
• La manipulation peut se comporter différemment
• Le glisser-déplacer ne réagit pas correctement à l’entrée tactile
• Cela n’affecte pas l’entrée du stylet
• Le glisser-déplacer ne peut plus être lancé par des événements tactiles/du stylet
• Cela peut éventuellement entraîner une absence de réponse de la part de l’application jusqu’à ce que l’entrée de la souris soit détectée.
• Au lieu de cela, les développeurs doivent lancer le glisser-déplacer à partir des événements de souris.

Suggestion

Les développeurs qui souhaitent activer cette pile peuvent ajouter/fusionner les éléments suivants dans le fichier App.config de l’application :

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Input.Stylus.EnablePointerSupport=true"/>
</runtime>
</configuration>

La suppression de cette entrée ou l’affectation de la valeur false désactive cette pile facultative. Notez que cette pile est uniquement disponible sur Windows 10 Creators Update et ultérieur.

Nom	Valeur
Étendue	Edge
Version	4,7
Type	Reciblage

Windows Workflow Foundation (WF)

Sommes de contrôle de flux de travail passées de MD5 à SHA1

Détails

Pour prendre en charge le débogage avec Visual Studio, l’exécution du flux de travail génère une somme de contrôle pour une instance de flux de travail à l’aide d’un algorithme de hachage. Dans .NET Framework 4.6.2 et les versions antérieures, le hachage de somme de contrôle de flux de travail utilisait l’algorithme MD5, ce qui entraînait des problèmes sur les systèmes compatibles FIPS. À compter de .NET Framework 4.7, l’algorithme est SHA1. Si votre code a rendu persistant ces sommes de contrôle, elles seront incompatibles.

Suggestion

Si votre code ne peut pas charger des instances de flux de travail en raison d’un échec de la somme de contrôle, essayez de définir le commutateur AppContext« Switch.System.Activities.UseMD5ForWFDebugger » sur true. Dans le code :

System.AppContext.SetSwitch("Switch.System.Activities.UseMD5ForWFDebugger", true);

Ou dans la configuration :

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Activities.UseMD5ForWFDebugger=true" />
  </runtime>
</configuration>

Nom	Valeur
Étendue	Secondaire
Version	4,7
Type	Reciblage

.NET Framework 4.7.1

ASP.NET

Améliorations de l’accessibilité ASP.NET dans .NET Framework 4.7.1

Détails

À compter de .NET Framework 4.7.1, ASP.NET a amélioré le fonctionnement des contrôles web ASP.NET avec la technologie d’accessibilité de Visual Studio pour une meilleure prise en charge des clients ASP.NET. Citons notamment les changements suivants :

• Changements visant à implémenter les modèles d’accessibilité de l’interface utilisateur manquants dans les contrôles, comme la boîte de dialogue Ajouter un champ de l’Assistant de la vue Détails ou la boîte de dialogue Configurer ListView de l’Assistant ListView.
• Changements visant à améliorer l’affichage en mode de contraste élevé, comme l’éditeur de champs du pagineur de données.
• Changements visant à améliorer les expériences de navigation au clavier pour les contrôles, comme la boîte de dialogue Champs de l’Assistant Modifier les champs pager du contrôle DataPager, la boîte de dialogue Configurer ObjectContext ou la boîte de dialogue Configurer la sélection de données de l’Assistant Configurer la source de données.

Suggestion

Comment accepter ou refuser ces changements Pour que le concepteur Visual Studio tire parti de ces changements, il doit s’exécuter sur .NET Framework 4.7.1 ou ultérieur. Pour que l’application web tire parti de ces changements, procédez de l’une des manières suivantes :

• Installez Visual Studio 2017 15.3 ou une version ultérieure, qui prend en charge les nouvelles fonctionnalités d’accessibilité avec le commutateur AppContext suivant par défaut.
• Refusez les comportements d’accessibilité hérités en ajoutant le commutateur AppContext Switch.UseLegacyAccessibilityFeatures à la section <runtime> du fichier devenv.exe.config et en lui affectant la valeur false, comme indiqué dans l’exemple suivant.

<?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>

Si votre application cible .NET Framework 4.7.1 ou une version ultérieure et que vous souhaitez conserver le comportement d’accessibilité hérité, choisissez d’utiliser les fonctionnalités d’accessibilité héritées en affectant explicitement à ce commutateur AppContext la valeur true.

Nom	Valeur
Étendue	Secondaire
Version	4.7.1
Type	Reciblage

Core

Exceptions de thread d’arrière-plan SerialPort

Détails

Les threads d’arrière-plan créés avec des flux SerialPort ne terminent plus le processus quand des exceptions de système d’exploitation sont levées.
Dans les applications qui ciblent .NET Framework 4.7 et les versions antérieures, un processus est terminé quand une exception de système d’exploitation est levée sur un thread d’arrière-plan créé avec un flux SerialPort.
Dans les applications qui ciblent .NET Framework 4.7.1 ou une version ultérieure, les threads d’arrière-plan attendent la fin des événements de système d’exploitation liés au port série actif et peuvent planter dans certains cas, comme la suppression soudaine du port série.

Suggestion

Pour les applications qui ciblent .NET Framework 4.7.1, vous pouvez refuser la gestion des exceptions en ajoutant le code suivant à la section <runtime> de votre fichier app.config :

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

Pour les applications qui ciblent des versions antérieures du .NET Framework mais qui s’exécutent sur .NET Framework 4.7.1 ou une version ultérieure, vous pouvez accepter la prise en charge de la gestion des exceptions en ajoutant le code suivant à la section <runtime> de votre fichier app.config :

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

Nom	Valeur
Étendue	Secondaire
Version	4.7.1
Type	Reciblage

API affectées

• System.IO.Ports.SerialPort

ServiceBase ne propage pas les exceptions OnStart

Détails

Dans .NET Framework 4.7 et antérieur, les exceptions levées au démarrage du service ne sont pas propagées à l’appelant de ServiceBase.Run.

À compter des applications qui ciblent .NET Framework 4.7.1, le runtime propage les exceptions à ServiceBase.Run pour les services qui ne parviennent pas à démarrer.

Suggestion

Au démarrage du service, si une exception est rencontrée, cette exception est propagée. Le diagnostic des cas où les services ne parviennent pas à démarrer devrait s’en trouver facilité.

Si ce comportement n’est pas souhaitable, vous pouvez choisir de l’annuler en ajoutant l’élément AppContextSwitchOverrides à la section runtime du fichier de configuration de votre application :

<AppContextSwitchOverrides value="Switch.System.ServiceProcess.DontThrowExceptionsOnStart=true" />

Si votre application cible une version antérieure à 4.7.1 mais que vous voulez avoir ce comportement, ajoutez l’élément AppContextSwitchOverrides suivant à la section runtime de votre fichier de configuration d’application :

<AppContextSwitchOverrides value="Switch.System.ServiceProcess.DontThrowExceptionsOnStart=false" />

Nom	Valeur
Étendue	Secondaire
Version	4.7.1
Type	Reciblage

API affectées

• ServiceBase.Run(ServiceBase)
• ServiceBase.Run(ServiceBase[])

Sécurité

Valeur par défaut des algorithmes SignedXML et SignedXMS remplacée par SHA256

Détails

Dans .NET Framework 4.7 et les versions antérieures, SignedXML et SignedCMS utilisent par défaut SHA1 pour certaines opérations. À compter de .NET Framework 4.7.1, SHA256 est activé par défaut pour ces opérations. Ce changement est nécessaire car SHA1 n’est plus considérée comme sécurisé.

Suggestion

Deux nouvelles valeurs de commutateur de contexte permettent de contrôler si SHA1 (non sécurisé) ou SHA256 est utilisé par défaut :

• Switch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithms
• Switch.System.Security.Cryptography.Pkcs.UseInsecureHashAlgorithms Pour les applications qui ciblent .NET Framework 4.7.1 et versions ultérieures, si l’utilisation de SHA256 n’est pas souhaitable, vous pouvez rétablir SHA1 comme valeur par défaut en ajoutant le commutateur de configuration suivant à la section runtime du fichier de configuration de votre application :

<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithms=true;Switch.System.Security.Cryptography.Pkcs.UseInsecureHashAlgorithms=true" />

Pour les applications que ciblent .NET Framework 4.7 et les versions antérieures, vous pouvez accepter ce changement en ajoutant le commutateur de configuration suivant à la section runtime de votre fichier de configuration d’application :

<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithms=false;Switch.System.Security.Cryptography.Pkcs.UseInsecureHashAlgorithms=false" />

Nom	Valeur
Étendue	Secondaire
Version	4.7.1
Type	Reciblage

API affectées

• System.Security.Cryptography.Pkcs.CmsSigner
• System.Security.Cryptography.Xml.SignedXml
• System.Security.Cryptography.Xml.Reference

SignedXml.GetPublicKey retourne RSACng sur net462 (ou lightup) sans changement de reciblage

Détails

À compter de .NET Framework 4.6.2, le type concret de l’objet retourné par la méthode SignedXml.GetPublicKey est passé (sans coïncidence) d’une implémentation CryptoServiceProvider à une implémentation Cng. La raison en est que l’implémentation est passée de l’utilisation de certificate.PublicKey.Key à l’utilisation du certificate.GetAnyPublicKey interne qu’elle transfère à RSACertificateExtensions.GetRSAPublicKey.

Suggestion

À partir des applications qui s’exécutent sur .NET Framework 4.7.1, vous pouvez utiliser l’implémentation CryptoServiceProvider utilisée par défaut dans .NET Framework 4.6.1 et les versions antérieures en ajoutant le commutateur de configuration suivant à la section runtime de votre fichier de configuration d’application :

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

Nom	Valeur
Étendue	Edge
Version	4.6.2
Type	Reciblage

API affectées

• SignedXml.CheckSignatureReturningKey(AsymmetricAlgorithm)

Windows Communication Foundation (WCF)

Amélioration de l’accessibilité pour certains outils du SDK .NET

Détails

Dans le kit .NET Framework SDK 4.7.1, les outils SvcConfigEditor.exe et SvcTraceViewer.exe ont été améliorés en corrigeant différents problèmes d’accessibilité. La plupart étaient des petits problèmes comme un nom non défini ou certains modèles d’automatisation de l’interface utilisateur non implémentés correctement. Contrairement à de nombreux utilisateurs qui n’ont pas conscience de ces valeurs incorrectes, les clients qui utilisent des technologies d’assistance comme les lecteurs d’écran trouveront ces outils SDK plus accessibles. Il est évident que ces correctifs changent certains comportements précédents, comme l’ordre de focus clavier. Pour obtenir tous les correctifs liés à l’accessibilité dans ces outils, vous pouvez ajouter ce qui suit à votre fichier app.config :

<runtime>
  <AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false"/>
</runtime>

Nom	Valeur
Étendue	Edge
Version	4.7.1
Type	Reciblage

Windows Forms

Améliorations apportées aux fonctionnalités d’accessibilité dans les contrôles Windows Forms

Détails

Windows Forms améliore la façon dont il utilise les technologies d’accessibilité pour mieux répondre aux besoins de ses clients. Elles présentent notamment les changements suivants, à compter de .NET Framework 4.7.1 :

• Changements visant à améliorer l’affichage en mode Contraste élevé.
• Changements visant à améliorer l’expérience dans l’explorateur de propriétés. Améliorations apportées à l’explorateur de propriétés. Parmi celles-ci :
• Une meilleure navigation au clavier via les différentes fenêtres de sélection de liste déroulante.
• Une réduction des taquets de tabulation inutiles.
• Des rapports plus élaborés sur les types de contrôles.
• Un comportement amélioré du Narrateur.
• Changements visant à implémenter les modèles d’accessibilité de l’interface utilisateur manquants dans les contrôles.

Suggestion

Comment accepter ou refuser ces changements L’application doit s’exécuter sur .NET Framework 4.7.1 ou ultérieur pour tirer parti de ces changements. Pour que l’application bénéficie de ces changements, procédez de l’une des manières suivantes :

• Recompilez-la pour qu’elle cible le .NET Framework 4.7.1. Ces changements d’accessibilité sont activés par défaut sur les applications Windows Forms qui ciblent le .NET Framework 4.7.1 ou ultérieur.
• Refusez les comportements d’accessibilité hérités en ajoutant le commutateur AppContext suivant à la section <runtime> du fichier app.config et en lui affectant la valeur false, comme dans l’exemple suivant.

<?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>

Si votre application cible .NET Framework 4.7.1 ou une version ultérieure et que vous souhaitez conserver le comportement d’accessibilité hérité, choisissez d’utiliser les fonctionnalités d’accessibilité héritées en affectant explicitement à ce commutateur AppContext la valeur true.

Pour une vue d’ensemble d’UI Automation, consultez la Vue d’ensemble d’UI Automation.

Ajout de la prise en charge des modèles et propriétés UI Automation

Les clients d’accessibilité peuvent tirer parti des nouvelles fonctionnalités d’accessibilité WinForms à l’aide de modèles d’appel courants décrits publiquement. Ces modèles ne sont pas spécifiques à WinForms. Par exemple, les clients d’accessibilité peuvent appeler la méthode QueryInterface sur l’interface IAccessible (MAAS) pour obtenir une interface IServiceProvider. Si cette interface est disponible, les clients peuvent utiliser sa méthode QueryService pour demander une interface IAccessibleEx. Pour plus d’informations, consultez Utilisation d’IAccessibleEx à partir d’un client. À compter de .NET Framework 4.7.1, IServiceProvider et IAccessibleEx (le cas échéant) sont disponibles pour les objets d’accessibilité WinForms.

.NET Framework 4.7.1 ajoute la prise en charge des modèles et des propriétés UI Automation suivants :

• Les contrôles ToolStripSplitButton et ComboBox prennent en charge le modèle Développer/Réduire.

• Le contrôle ToolStripMenuItem a une valeur de propriété ControlType égale à ControlType.MenuItem.

• Le contrôle ToolStripItem prend en charge la propriété NameProperty et le modèle Développer/Réduire.

• Le contrôle ToolStripDropDownItem prend en charge AccessibleEvents indiquant StateChange et NameChange quand la liste déroulante est développée ou réduite.

• Le contrôle ToolStripDropDownButton a une valeur de propriété ControlType égale à ControlType.MenuItem.

• Le contrôle DataGridViewCheckBoxCell prend en charge TogglePattern.

• Les contrôles NumericUpDown et DomainUpDown prennent en charge la propriété NameProperty et ont un ControlType égal à ControlType.Spinner.

  Améliorations apportées au contrôle PropertyGrid .NET Framework 4.7.1 ajoute les améliorations suivantes au contrôle PropertyBrowser :

• Le bouton Détails, qui se trouve dans la boîte de dialogue d’erreur qui s’affiche quand l’utilisateur entre une valeur incorrecte dans le contrôle PropertyGrid, prend en charge le modèle Développer/Réduire, les notifications de changement de nom et d’état, et une propriété ControlType avec la valeur ControlType.MenuItem.

• Le volet de messages, qui s’affiche quand le bouton Détails de la boîte de dialogue d’erreur est développé, est désormais accessible au moyen du clavier et permet au Narrateur d’annoncer le contenu du message d’erreur.

• Le paramètre AccessibleRole des lignes dans le contrôle PropertyGrid est passé de « Row » à « Cell ». La cellule est mappée au ControlType UIA DataItem, ce qui lui permet de prendre en charge les raccourcis clavier appropriés et les annonces du Narrateur.

• Les lignes du contrôle PropertyGrid qui représentent les éléments d’en-tête quand le contrôle PropertyGrid a une propriété PropertySort dont la valeur est PropertySort.Categorized ont une valeur de propriété ControlType égale à ControlType.Button.

• Les lignes du contrôle PropertyGrid qui représentent les éléments d’en-tête lorsque la propriété PropertySort du contrôle PropertyGrid est définie sur PropertySort.Categorized prennent en charge le modèle Développer/Réduire.

• Navigation au clavier améliorée entre la grille et de la barre d’outils située au-dessus. La combinaison de touches Maj+Tab permet désormais de sélectionner le premier bouton de la barre d’outils, et non la barre d’outils tout entière.

• Les contrôles PropertyGrid affichés en mode Contraste élevé dessinent désormais un rectangle de focus autour du bouton de barre d’outils qui correspond à la valeur de propriété PropertySort actuelle.

• Les contrôles PropertyGrid affichés en mode Contraste élevé et dont la propriété PropertySort est définie avec la valeur PropertySort.Categorized affichent désormais l’arrière-plan des en-têtes de catégorie dans une couleur très contrastée.

• Les contrôles PropertyGrid permettent de mieux distinguer les éléments de barre d’outils ayant le focus de ceux qui indiquent la valeur actuelle de la propriété PropertySort. Ce correctif se compose de deux changements : l’un visant le mode Contraste élevé et l’autre les scénarios n’utilisant pas ce mode.

• Les éléments de barre d’outils du contrôle PropertyGrid, qui indiquent la valeur actuelle de la propriété PropertySort, prennent en charge TogglePattern.

• Prise en charge améliorée du Narrateur pour distinguer l’alignement sélectionné dans le sélecteur d’alignement.

• Quand un contrôle PropertyGrid vide est affiché sur un formulaire, il reçoit désormais le focus. Ce n’était pas le cas avant.

Utilisation des couleurs définies par le système d’exploitation dans les thèmes à contraste élevé

• Les contrôles Button et CheckBox dont la propriété FlatStyle est définie avec la valeur FlatStyle.System, le style par défaut, utilisent désormais les couleurs définies par le système d’exploitation dans le thème à contraste élevé quand celui-ci est sélectionné. Avant, les couleurs du texte et de l’arrière-plan n’étaient pas contrastées et étaient difficiles à lire.
• Les contrôles Button, CheckBox, RadioButton, Label, LinkLabel et GroupBox dont la propriété Enabled est définie avec la valeur false utilisaient une couleur ombrée pour afficher le texte dans les thèmes à contraste élevé, ce qui aboutissait à un faible contraste par rapport à l’arrière-plan. Ces contrôles utilisent à présent la couleur « Texte désactivé » définie par le système d’exploitation. Ce correctif s’applique aux contrôles dont la propriété FlatStyle est définie avec une valeur autre que FlatStyle.System. Ces derniers contrôles sont affichés par le système d’exploitation.
• DataGridView affiche maintenant un rectangle visible autour du contenu de la cellule qui a le focus. Ce rectangle était invisible dans certains thèmes à contraste élevé.
• Les contrôles ToolStripMenuItem dont la propriété Enabled est définie sur false utilisent maintenant la couleur « Texte désactivé » définie par le système d’exploitation.
• Les contrôles ToolStripMenuItem dont la propriété Checked a la valeur true affichent maintenant la coche associée dans une couleur système contrastée. Avant, la couleur de la coche n’était pas suffisamment contrastée et était invisible dans les thèmes à contraste élevé. REMARQUE : Les valeurs de certaines couleurs système à contraste élevé ont changé dans Windows 10. Windows Forms Framework est basé sur le framework Win32. Pour une expérience optimale, utilisez la dernière version de Windows et acceptez les derniers changements du système d’exploitation en ajoutant un fichier app.manifest dans une application de test et en supprimant le commentaire du code suivant :

<!-- Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />

Navigation au clavier améliorée

• Quand la propriété DropDownStyle d’un contrôle ComboBox a la valeur ComboBoxStyle.DropDownList et qu’il s’agit du premier contrôle dans l’ordre de tabulation sur le formulaire, un rectangle de focus apparaît désormais quand le formulaire parent est ouvert à l’aide du clavier. Avant ce changement, le focus clavier était sur ce contrôle, mais aucun indicateur de focus n’était affiché.

Amélioration de la prise en charge du Narrateur

• Le contrôle MonthCalendar prend désormais en charge les technologies d’assistance pour accéder au contrôle, notamment la possibilité pour le Narrateur de lire la valeur du contrôle, ce qui n’était pas possible avant.

• Le contrôle CheckedListBox avertit désormais le Narrateur quand une propriété CheckBox.CheckState change. Le Narrateur ne recevait aucune notification, et les utilisateurs n’étaient pas informés de la mise à jour de la propriété CheckState.

• Le contrôle LinkLabel notifie le Narrateur du texte présent dans le contrôle de manière différente. Avant, le Narrateur annonçait ce texte à deux reprises et lisait les symboles "&" comme du texte réel, alors qu’ils n’étaient pas visibles. Le texte en double a été supprimé des annonces du Narrateur, ainsi que les symboles "&" inutiles.

• Les types de contrôle DataGridViewCell signalent désormais correctement l’état en lecture seule au Narrateur et à d’autres technologies d’assistance.

• Le Narrateur peut désormais lire le menu système des fenêtres enfants dans les applications [Multiple-Document Interface]~/docs/framework/winforms/advanced/multiple-document-interface-mdi-applications.md).

• Le Narrateur peut désormais lire les contrôles ToolStripMenuItem dont la propriété ToolStripItem.Enabled a la valeur false. Avant, le Narrateur ne pouvait pas lire le contenu des éléments de menu désactivés.

Nom	Valeur
Étendue	Majeure
Version	4.8
Type	Reciblage

API affectées

• ToolStripDropDownButton.CreateAccessibilityInstance()
• DomainUpDown.DomainUpDownAccessibleObject.Name
• MonthCalendar.AccessibilityObject

Windows Presentation Foundation (WPF)

Améliorations apportées aux fonctionnalités d’accessibilité dans WPF

Détails

Améliorations apportées au mode Contraste élevé

• Le focus pour le contrôle Expander est désormais visible. Dans les versions précédentes de .NET Framework, ce n’était pas le cas.
• Quand les contrôles CheckBox et RadioButton sont sélectionnés, le texte qu’ils contiennent est plus facile à voir que dans les versions précédentes du .NET Framework.
• La bordure d’un ComboBox désactivé est désormais de la même couleur que le texte désactivé. Dans les versions précédentes de .NET Framework, ce n’était pas le cas.
• Les boutons désactivés et ceux avec le focus utilisent désormais la bonne couleur de thème. Dans les versions précédentes de .NET Framework, ce n’était pas le cas.
• Le bouton déroulant est désormais visible quand le style d’un contrôle ComboBox est défini sur ToolBar.ComboBoxStyleKey. Dans les versions précédentes de .NET Framework, ce n’était pas le cas.
• La flèche d’indicateur de tri dans un contrôle DataGrid utilise désormais les couleurs de thème. Dans les versions précédentes de .NET Framework, ce n’était pas le cas.
• Le style de lien hypertexte par défaut utilise désormais la bonne couleur de thème quand l’utilisateur pointe dessus avec la souris. Dans les versions précédentes de .NET Framework, ce n’était pas le cas.
• Le focus clavier sur les boutons radio est désormais visible. Dans les versions précédentes de .NET Framework, ce n’était pas le cas.
• La colonne de cases à cocher du contrôle DataGrid utilise désormais les couleurs attendues pour le focus clavier. Dans les versions précédentes de .NET Framework, ce n’était pas le cas.
• Les visuels du focus clavier sont désormais visibles sur les contrôles ComboBox et ListBox. Dans les versions précédentes de .NET Framework, ce n’était pas le cas.

Améliorations apportées à l’interaction avec le lecteur d’écran

• Les contrôles Expander sont maintenant correctement annoncés comme groupes (développer/réduire) par les lecteurs d’écran.
• Les contrôles DataGridCell sont maintenant correctement annoncés comme cellules de grille de données (version localisée) par les lecteurs d’écran.
• Les lecteurs d’écran annoncent désormais le nom d’un ComboBox modifiable.
• Les lecteurs d’écran n’annoncent plus « aucun élément dans la vue » pour décrire les contrôles PasswordBox.

Prise en charge des régions dynamiques

Les lecteurs d’écran, tels que le Narrateur, aident les utilisateurs à se familiariser avec l’interface utilisateur d’une application, généralement en décrivant l’élément d’interface utilisateur qui a actuellement le focus. Toutefois, si un élément de l’interface utilisateur n’a pas le focus et qu’il change à l’écran, l’utilisateur peut passer à côté d’informations importantes s’il n’en est pas informé. Les régions dynamiques sont conçues pour résoudre ce problème. Un développeur peut les utiliser pour informer le lecteur d’écran ou tout autre client UI Automation qu’un changement important a été apporté à un élément d’interface utilisateur. Le lecteur d’écran peut ensuite décider comment et quand informer l’utilisateur de cette modification. La propriété LiveSetting indique également au lecteur d’écran qu’il est important d’informer l’utilisateur du changement apporté à l’interface utilisateur.

Suggestion

Accepter ou refuser ces modifications

L’application doit s’exécuter sur .NET Framework 4.7.1 ou ultérieur pour tirer parti de ces changements. Pour que l’application bénéficie de ces changements, procédez de l’une des manières suivantes :

• Ciblez .NET Framework 4.7.1. Il s’agit de l’approche recommandée. Ces changements d’accessibilité sont activés par défaut sur les applications WPF qui ciblent .NET Framework 4.7.1 ou ultérieur.

• Refusez les comportements d’accessibilité hérités en ajoutant le commutateur AppContext suivant à la section <runtime> du fichier de configuration de l’application et en lui affectant la valeur false, comme dans l’exemple suivant.

  <?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>
  

Si votre application cible .NET Framework 4.7.1 ou une version ultérieure et que vous souhaitez conserver le comportement d’accessibilité hérité, choisissez d’utiliser les fonctionnalités d’accessibilité héritées en affectant explicitement à ce commutateur AppContext la valeur true. Pour une vue d’ensemble d’UI Automation, consultez Vue d’ensemble d’UI Automation.

Nom	Valeur
Étendue	Majeure
Version	4.7.1
Type	Reciblage

API affectées

• AutomationElementIdentifiers.LiveSettingProperty
• AutomationElementIdentifiers.LiveRegionChangedEvent
• System.Windows.Automation.AutomationLiveSetting
• AutomationProperties.LiveSettingProperty
• AutomationProperties.SetLiveSetting(DependencyObject, AutomationLiveSetting)
• AutomationProperties.GetLiveSetting(DependencyObject)
• AutomationPeer.GetLiveSettingCore()

Événement SelectionChanged et propriété SelectedValue de Selector

Détails

À compter de .NET Framework 4.7.1, un Selector met toujours à jour la valeur de sa propriété SelectedValue avant de déclencher l’événement SelectionChanged quand sa sélection change. La propriété SelectedValue est ainsi cohérente avec les autres propriétés de sélection (SelectedItem et SelectedIndex), qui sont mises à jour avant le déclenchement de l’événement.

Dans .NET Framework 4.7 et antérieur, la mise à jour de SelectedValue avait lieu avant l’événement dans la plupart des cas, mais elle se produisait après l’événement si le changement de sélection résultait du changement de la propriété SelectedValue.

Suggestion

Les applications qui ciblent .NET Framework 4.7.1 ou ultérieur peuvent refuser ce changement et utiliser le comportement hérité en ajoutant le code suivant à la section <runtime> du fichier de configuration d’application :

<runtime>
<AppContextSwitchOverrides
value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=true" />
</runtime>

Les applications qui ciblent .NET Framework 4.7 ou antérieur mais qui s’exécutent sur .NET Framework 4.7.1 ou ultérieur peuvent activer le nouveau comportement en ajoutant la ligne suivante à la section <runtime> du fichier .configuration de l’application :

<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=false" />
</runtime>

Nom	Valeur
Étendue	Secondaire
Version	4.7.1
Type	Reciblage

API affectées

• TabControl.SelectedContent
• Selector.SelectionChanged

Événement TabControl SelectionChanged et propriété SelectedContent

Détails

À compter de .NET Framework 4.7.1, un TabControl met à jour la valeur de sa propriété SelectedContent avant de déclencher l’événement SelectionChanged quand sa sélection change. Dans .NET Framework 4.7 et antérieur, la mise à jour de SelectedContent se produisait après l’événement.

Suggestion

Les applications qui ciblent .NET Framework 4.7.1 ou ultérieur peuvent refuser ce changement et utiliser le comportement hérité en ajoutant le code suivant à la section <runtime> du fichier de configuration d’application :

<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=true" />
</runtime>

Les applications qui ciblent .NET Framework 4.7 ou antérieur mais qui s’exécutent sur .NET Framework 4.7.1 ou ultérieur peuvent activer le nouveau comportement en ajoutant la ligne suivante à la section <runtime> du fichier .configuration de l’application :

<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=false" />
</runtime>

Nom	Valeur
Étendue	Secondaire
Version	4.7.1
Type	Reciblage

API affectées

• TabControl.SelectedContent
• Selector.SelectionChanged

L’algorithme de hachage par défaut pour WPF PackageDigitalSignatureManager est désormais SHA256

Détails

System.IO.Packaging.PackageDigitalSignatureManager fournit des fonctionnalités pour les signatures numériques en relation avec les packages WPF. Dans le .NET Framework 4.7 et versions antérieures, l’algorithme par défaut (PackageDigitalSignatureManager.DefaultHashAlgorithm) utilisé pour la signature des parties d’un package était SHA1. En raison des récents problèmes de sécurité avec SHA1, cette valeur par défaut est remplacée par SHA256 à compter du .NET Framework 4.7.1. Ce changement affecte toutes les signatures de package, notamment les documents XPS.

Suggestion

Un développeur qui souhaite utiliser ce changement tout en ciblant une version antérieure à .NET Framework 4.7.1 ou un développeur qui nécessite les fonctionnalités précédentes tout en ciblant .NET Framework 4.7.1 ou ultérieur peut définir l’indicateur AppContext en conséquence. La valeur true signifie que SHA1 est utilisé comme algorithme par défaut ; false entraîne l’utilisation de SHA256.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.MS.Internal.UseSha1AsDefaultHashAlgorithmForDigitalSignatures=true"/>
</runtime>
</configuration>

Nom	Valeur
Étendue	Edge
Version	4.7.1
Type	Reciblage

API affectées

• PackageDigitalSignatureManager.DefaultHashAlgorithm

Windows Workflow Foundation (WF)

Améliorations de l’accessibilité dans le Concepteur de flux de travail Windows Workflow Foundation (WF)

Détails

Le Concepteur de flux de travail Windows Workflow Foundation (WF) améliore son fonctionnement avec les technologies d’accessibilité. Ces améliorations incluent notamment les changements suivants :

• L’ordre de tabulation est modifié pour passer de gauche à droite et de haut en bas dans certains contrôles :
• La fenêtre d’initialisation de la corrélation pour définir les données de corrélation pour l’activité InitializeCorrelation
• La fenêtre de définition du contenu pour les activités Receive, Send, SendReply et ReceiveReply
• D’autres fonctions sont disponibles par le biais du clavier :
• Quand vous modifiez les propriétés d’une activité, les groupes de propriétés peuvent être réduits à l’aide du clavier la première fois qu’ils ont le focus.
• Des icônes d’avertissement sont désormais accessibles à l’aide du clavier.
• Le bouton Plus de propriétés de la fenêtre Propriétés est désormais accessible à l’aide du clavier.
• Les utilisateurs du clavier peuvent désormais accéder aux éléments d’en-tête dans les volets Arguments et Variables du Concepteur de flux de travail.
• Une meilleure visibilité des éléments ayant le focus, par exemple dans les cas suivants :
• Ajout de lignes dans des grilles de données utilisées par le Concepteur de flux de travail et les concepteurs d’activités.
• Déplacement par tabulation dans les champs des activités ReceiveReply et SendReply.
• Définition de valeurs par défaut pour les variables ou les arguments
• Les lecteurs d’écran peuvent désormais reconnaître correctement :
• Les points d’arrêt définis dans le Concepteur de flux de travail.
• Les activités FlowSwitch<T>, FlowDecision et CorrelationScope.
• Le contenu de l’activité Receive.
• Le type cible pour l’activité InvokeMethod.
• La zone de liste déroulante Exception et la section Finally de l’activité TryCatch.
• La zone de liste déroulante Type de message, le séparateur dans la fenêtre Ajouter des initialiseurs de corrélation, la fenêtre de définition du contenu et la fenêtre Définition de CorrelatesOn dans les activités de messagerie (Receive, Send, SendReply et ReceiveReply).
• Transitions d’ordinateur d’état et destination des transitions.
• Annotations et connecteurs sur les activités FlowDecision.
• Les menus contextuels (accessibles en cliquant avec le bouton droit) pour les activités.
• Les éditeurs de valeurs de propriété, le bouton Effacer la recherche, les boutons a catégorie par et boutons de tri Par catégorie et Ordre alphabétique et la boîte de dialogue Éditeur d’expressions dans la grille des propriétés.
• Le pourcentage de zoom dans le Concepteur de flux de travail.
• Le séparateur dans les activités Parallel et Pick.
• L’activité InvokeDelegate.
• La fenêtre Sélectionner les types pour les activités de dictionnaire (Microsoft.Activities.AddToDictionary<TKey,TValue>, Microsoft.Activities.RemoveFromDictionary<TKey,TValue>, etc.).
• La fenêtre Rechercher et sélectionner un type .NET.
• Les barres de navigation dans le Concepteur de flux de travail.
• Les utilisateurs qui choisissent des thèmes à contraste élevé verront de nombreuses améliorations de la visibilité du Concepteur de flux de travail et de ses contrôles, comme de meilleurs rapports de contraste entre les éléments et des zones de sélection plus visibles utilisées pour les éléments ayant le focus.

Suggestion

Si vous avez une application avec un Concepteur de flux de travail réhébergé, effectuez l’une des actions suivantes pour qu’elle bénéficie de ces changements :

• Recompilez votre application pour cibler .NET Framework 4.7.1. Ces changements de l’accessibilité sont activés par défaut.
• Si votre application cible .NET Framework 4.7 ou une version antérieure mais qu’elle s’exécute sur .NET Framework 4.7.1, vous pouvez refuser ces comportements d’accessibilité hérités en ajoutant le commutateur AppContext suivant à la section <runtime> du fichier app.config et en lui affectant la valeur false, comme indiqué dans l’exemple suivant.

<?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>

Si votre application cible .NET Framework 4.7.1 ou une version ultérieure et que vous souhaitez conserver le comportement d’accessibilité hérité, choisissez d’utiliser les fonctionnalités d’accessibilité héritées en affectant explicitement à ce commutateur AppContext la valeur true.

Nom	Valeur
Étendue	Secondaire
Version	4.7.1
Type	Reciblage

.NET Framework 4.7.2

Principal

Autoriser les caractères de contrôle bidirectionnels Unicode dans les URI

Détails

Unicode spécifie plusieurs caractères de contrôle spéciaux utilisés pour définir l’orientation du texte. Dans les versions précédentes du .NET Framework, ces caractères n’étaient pas correctement supprimés de tous les URI, même s’ils étaient encodés en pourcentage. Pour mieux suivre la spécification RFC 3987, nous autorisons désormais ces caractères dans les URI. Si une URI en contient qui ne sont pas encodés, ils sont encodés en pourcentage. Si elle en contient qui sont encodés en pourcentage, ils sont laissés tels quels.

Suggestion

Pour les applications qui ciblent des versions du .NET Framework à partir de la version 4.7.2, la prise en charge des caractères bidirectionnels Unicode est activée par défaut. Si ce changement n’est pas souhaitable, vous pouvez le désactiver en ajoutant le commutateur AppContextSwitchOverrides suivant à la section <runtime> du fichier de configuration d’application :

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

Pour les applications qui ciblent des versions antérieures du .NET Framework, mais qui s’exécutent sur .NET Framework versions 4.7.2 et ultérieures, la prise en charge des caractères bidirectionnels Unicode est désactivée par défaut. Vous pouvez l’activer en ajoutant le commutateur AppContextSwitchOverrides suivant à la section <runtime> du fichier de configuration d’application :

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

Nom	Valeur
Étendue	Secondaire
Version	4.7.2
Type	Reciblage

API affectées

• System.Uri

DeflateStream utilise des API natives pour la décompression

Détails

À compter de .NET Framework 4.7.2, l’implémentation de la décompression de la classe T:System.IO.Compression.DeflateStream a été changée de façon à utiliser des API Windows natives par défaut. En règle générale, s’ensuit une amélioration sensible des performances. Toutes les applications .NET ciblant .NET Framework versions 4.7.2 ou ultérieures utilisent l’implémentation native. Ce changement peut entraîner certaines différences de comportement, notamment les suivantes :

• Les messages d’exception peuvent être différents. Toutefois, le type d’exception levée reste le même.
• Certaines situations particulières, telles que le manque de mémoire pour effectuer une opération, peuvent être traitées différemment.
• Il existe des différences connues pour l’analyse de l’en-tête gzip (remarque : seul GZipStream défini pour la décompression est affecté) :
• Les exceptions pendant l’analyse d’en-têtes non valides peuvent être levées à des moments différents.
• L’implémentation native impose que les valeurs de certains indicateurs réservés à l’intérieur de l’en-tête gzip (c’est-à-dire, FLG) soient définies en fonction de la spécification ; elle risque donc de lever une exception au lieu d’ignorer les valeurs non valides.

Suggestion

Si la décompression avec des API natives a affecté le comportement de votre application, vous pouvez refuser cette fonctionnalité en ajoutant le commutateur Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression à la section runtime de votre fichier app.config et en le définissant sur true :

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression=true" />
  </runtime>
</configuration>

Nom	Valeur
Étendue	Secondaire
Version	4.7.2
Type	Reciblage

API affectées

• System.IO.Compression.DeflateStream
• System.IO.Compression.GZipStream

Vérifier que System.Uri utilise un jeu de caractères réservés cohérent

Détails

Dans System.Uri, certains caractères encodés en pourcentage qui étaient parfois décodés demeurent désormais systématiquement encodés. Cela se produit sur les propriétés et méthodes qui accèdent aux composants de chemin, de requête, de fragment ou d’informations utilisateur de l’URI. Le comportement change uniquement quand les deux conditions suivantes sont vraies :

• L’URI contient la forme encodée d’un des caractères réservés suivants : :, ', (, ), ! ou *.
• L’URI contient un caractère non réservé encodé ou Unicode. Si les deux conditions ci-dessus sont remplies, les caractères réservés encodés demeurent encodés. Dans les versions précédentes du .NET Framework, ils sont décodés.

Suggestion

Pour les applications qui ciblent les versions du .NET Framework à partir de la version 4.7.2, le nouveau comportement de décodage est activé par défaut. Si ce changement n’est pas souhaitable, vous pouvez le désactiver en ajoutant le commutateur AppContextSwitchOverrides suivant à la section <runtime> du fichier de configuration d’application :

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

Pour les applications qui ciblent des versions antérieures du .NET Framework, mais qui s’exécutent sur .NET Framework versions 4.7.2 et ultérieures, le nouveau comportement de décodage est désactivé par défaut. Vous pouvez l’activer en ajoutant le commutateur AppContextSwitchOverrides suivant à la section <runtime> du fichier de configuration de l’application :

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

Nom	Valeur
Étendue	Secondaire
Version	4.7.2
Type	Reciblage

API affectées

• System.Uri

Resgen refuse de charger du contenu à partir du web

Détails

Les fichiers .resx peuvent contenir une entrée au format binaire. Si vous tentez d’utiliser resgen pour charger un fichier téléchargé à partir d’un emplacement non approuvé, le chargement de l’entrée par défaut échoue.

Suggestion

Les utilisateurs de resgen qui ont besoin de charger une entrée au format binaire à partir d’emplacements non approuvés peuvent supprimer la marque du web du fichier d’entrée ou appliquer le quirk de refus. Ajoutez le paramètre de Registre suivant pour appliquer le quirk à l’échelle de l’ordinateur : [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\SDK] "AllowProcessOfUntrustedResourceFiles"="true"

Nom	Valeur
Étendue	Edge
Version	4.7.2
Type	Reciblage

Les traces obtenues durant l’utilisation de fichiers PDB portables incluent désormais les informations sur les lignes et les fichiers sources, si elles sont demandées

Détails

À compter de .NET Framework 4.7.2, les traces obtenues durant l’utilisation de fichiers PDB portables incluent les informations sur les lignes et les fichiers sources quand elles sont demandées. Dans les versions antérieures de .NET Framework 4.7.2, les informations sur les lignes et les fichiers sources n’étaient pas disponibles pendant l’utilisation de fichiers PDB portables même si elles étaient explicitement demandées.

Suggestion

Pour les applications qui ciblent .NET Framework 4.7.2, vous pouvez refuser les informations sur les lignes et les fichiers sources durant l’utilisation de fichiers PDB portables en ajoutant le code suivant à la section <runtime> de votre fichier app.config :

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

Pour les applications qui ciblent des versions antérieures de .NET Framework mais qui s’exécutent sur .NET Framework 4.7.2 ou une version ultérieure, vous pouvez accepter les informations sur les lignes et les fichiers sources durant l’utilisation de fichiers PDB portables en ajoutant le code suivant à la section <runtime> de votre fichier app.config :

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

Nom	Valeur
Étendue	Edge
Version	4.7.2
Type	Reciblage

API affectées

• StackTrace(Boolean)
• StackTrace(Exception, Boolean)
• StackTrace(Exception, Int32, Boolean)

Windows Forms

Améliorations apportées aux fonctionnalités d’accessibilité dans les contrôles Windows Forms pour .NET 4.7.2

Détails

Windows Forms Framework améliore la façon dont il utilise les technologies d’accessibilité pour mieux répondre aux besoins de ses clients. Citons notamment les changements suivants :

• Changements visant à améliorer l’affichage en mode Contraste élevé.
• Changements visant à améliorer la navigation au clavier dans les contrôles DataGridView et MenuStrip.
• Changements apportés à l’interaction avec le Narrateur.

Suggestion

Comment accepter ou refuser ces changements Pour tirer parti de ces changements, l’application doit s’exécuter sous .NET Framework 4.7.2 ou version ultérieure. Pour que l’application bénéficie de ces changements, procédez de l’une des manières suivantes :

• Recompilez-la pour qu’elle cible .NET Framework 4.7.2. Ces changements d’accessibilité sont activés par défaut sur les applications Windows Forms qui ciblent .NET Framework 4.7.2 ou ultérieur.
• Faites-lui cibler .NET Framework version 4.7.1 ou antérieure et refusez les comportements d’accessibilité hérités, en ajoutant le commutateur AppContext suivant à la section <runtime> du fichier de configuration de l’application et en lui affectant la valeur false, comme dans l’exemple suivant.

<?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>

Notez que pour accepter les fonctionnalités d’accessibilité ajoutées à .NET Framework 4.7.2, vous devez également accepter les fonctionnalités d’accessibilité de .NET Framework 4.7.1. Si votre application cible .NET Framework 4.7.2 ou une version ultérieure et que vous souhaitez conserver le comportement d’accessibilité hérité, choisissez d’utiliser les fonctionnalités d’accessibilité héritées en affectant explicitement à ce commutateur AppContext la valeur true.

Utilisation des couleurs définies par le système d’exploitation dans les thèmes à contraste élevé

• La flèche déroulante de ToolStripDropDownButton utilise désormais les couleurs définies par le système d’exploitation dans le thème à contraste élevé.
• Les contrôles Button, RadioButton et CheckBox dont le FlatStyle est défini avec la valeur FlatStyle.Flat ou FlatStyle.Popup utilisent désormais les couleurs définies par le système d’exploitation dans le thème à contraste élevé quand celui-ci est sélectionné. Avant, les couleurs du texte et de l’arrière-plan n’étaient pas contrastées et étaient difficiles à lire.
• Les contrôles à l’intérieur d’un GroupBox dont la propriété Enabled a pour valeur false utilisent désormais les couleurs définies par le système d’exploitation dans le thème à contraste élevé.
• Les contrôles ToolStripButton, ToolStripComboBox et ToolStripDropDownButton ont un ratio contraste/luminosité accru dans le mode à contraste élevé.
• DataGridViewLinkCell utilise par défaut les couleurs définies par le système d’exploitation en mode de contraste élevé pour la propriété DataGridViewLinkCell.LinkColor. REMARQUE : Les valeurs de certaines couleurs système à contraste élevé ont changé dans Windows 10. Windows Forms Framework est basé sur le framework Win32. Pour une expérience optimale, utilisez la dernière version de Windows et acceptez les derniers changements du système d’exploitation en ajoutant un fichier app.manifest dans une application de test et en supprimant le commentaire du code suivant :

<!-- Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />

Amélioration de la prise en charge du Narrateur

• Le Narrateur annonce désormais la valeur de la propriété ToolStripMenuItem.ShortcutKeys quand il annonce le texte d’un ToolStripMenuItem.
• Le Narrateur indique désormais quand un ToolStripMenuItem a sa propriété Enabled définie sur false.
• Le Narrateur fournit désormais des commentaires sur l’état d’une case à cocher quand la propriété ListView.CheckBoxes est définie sur true.
• L’ordre de focus du mode balayage du narrateur est maintenant cohérent avec l’ordre visuel des contrôles dans la fenêtre de dialogue de téléchargement ClickOnce.

Amélioration de la prise en charge de l’accessibilité DataGridView

• Les lignes dans un DataGridView peuvent désormais être triées à l’aide du clavier. Un utilisateur peut utiliser la touche F3 pour trier la colonne actuelle.
• Quand le DataGridView.SelectionMode est défini sur DataGridViewSelectionMode.FullRowSelect, l’en-tête de colonne change de couleur pour indiquer la colonne actuelle quand l’utilisateur passe d’une cellule à l’autre de la ligne actuelle à l’aide de la touche Tab.
• La propriété DataGridViewCell.DataGridViewCellAccessibleObject.Parent retourne désormais le contrôle parent approprié.

Amélioration des signaux visuels

• Les contrôles RadioButton et CheckBox avec une propriété Text vide affichent désormais un indicateur de focus quand ils reçoivent le focus.

Amélioration de la prise en charge de la grille de propriétés

• Les éléments enfants du contrôle PropertyGrid renvoient désormais un true pour la propriété IsReadOnlyProperty uniquement lorsqu’un élément PropertyGrid est activé.

• Les éléments enfants du contrôle PropertyGrid retournent désormais un false pour la propriété IsEnabledProperty uniquement quand un élément PropertyGrid peut être changé par l’utilisateur. Pour une vue d’ensemble d’UI Automation, consultez la Vue d’ensemble d’UI Automation.

  Navigation au clavier améliorée

• ToolStripButton accepte désormais le focus quand il est contenu dans un ToolStripPanel dont la propriété TabStop a la valeur true.

Nom	Valeur
Étendue	Majeure
Version	4.7.2
Type	Reciblage

La propriété ContextMenuStrip.SourceControl contient un contrôle valide dans le cas des ToolStripMenuItems imbriqués

Détails

Dans .NET Framework 4.7.1 et versions antérieures, la propriété ContextMenuStrip.SourceControl retourne la valeur null quand l’utilisateur ouvre le menu à partir de contrôles ToolStripMenuItem imbriqués. Dans .NET Framework 4.7.2 et versions ultérieures, la propriété SourceControl est toujours définie sur le contrôle de code source réel.

Suggestion

Comment accepter ou refuser ces changementsUne application doit s’exécuter sur .NET Framework 4.7.2 ou ultérieur pour tirer parti de ces changements. Pour que l’application bénéficie de ces changements, procédez de l’une des manières suivantes :

• Faites-lui cibler .NET Framework 4.7.2. Ce changement est activé par défaut sur les applications Windows Forms qui ciblent .NET Framework 4.7.2 ou ultérieur.
• Faites-lui cibler .NET Framework version 4.7.1 ou antérieure et refusez les comportements d’accessibilité hérités en ajoutant le commutateur AppContext suivant à la section <runtime> du fichier app.config et en lui affectant la valeur false, comme dans l’exemple suivant.

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

Si votre application cible .NET Framework 4.7.2 ou une version ultérieure et que vous souhaitez conserver le comportement hérité, choisissez d’utiliser la valeur de contrôle de code source héritée en affectant explicitement à ce commutateur AppContext la valeur true.

Nom	Valeur
Étendue	Edge
Version	4.7.2
Type	Reciblage

API affectées

• ContextMenuStrip.SourceControl

La méthode PrivateFontCollection.AddFontFile libère les ressources de police

Détails

Dans .NET Framework 4.7.1 et versions antérieures, une fois le PrivateFontCollection supprimé pour les objets Font, la classe System.Drawing.Text.PrivateFontCollection ne libère pas les ressources de police GDI+ qui sont ajoutées à cette collection à l’aide de la méthode AddFontFile(String). Dans .NET Framework 4.7.2 et versions ultérieures, Dispose libère les polices GDI+ qui ont été ajoutées à la collection en tant que fichiers.

Suggestion

Comment accepter ou refuser ces changementsUne application doit s’exécuter sur .NET Framework 4.7.2 ou ultérieur pour tirer parti de ces changements. Pour que l’application bénéficie de ces changements, procédez de l’une des manières suivantes :

• Recompilez-la pour qu’elle cible .NET Framework 4.7.2. Ce changement est activé par défaut sur les applications Windows Forms qui ciblent .NET Framework 4.7.2 ou ultérieur.
• Faites-lui cibler .NET Framework version 4.7.1 ou antérieure et refusez les comportements d’accessibilité hérités en ajoutant le commutateur AppContext suivant à la section <runtime> du fichier app.config et en lui affectant la valeur false, comme dans l’exemple suivant.

<runtime>
<AppContextSwitchOverrides value="Switch.System.Drawing.Text.DoNotRemoveGdiFontsResourcesFromFontCollection=false"/>
</runtime>

Si votre application cible .NET Framework 4.7.2 ou une version ultérieure et que vous souhaitez conserver le comportement hérité, choisissez de ne pas libérer les ressources de police en affectant explicitement à ce commutateur AppContext la valeur true.

Nom	Valeur
Étendue	Edge
Version	4.7.2
Type	Reciblage

API affectées

• PrivateFontCollection.AddFontFile(String)
• FontCollection.Dispose()

Les actions upbutton et downbutton Domain de WinForm sont désormais synchronisées

Détails

Dans .NET Framework 4.7.1 et versions antérieures, l’action DomainUpDown.UpButton() du contrôle DomainUpDown est ignorée quand le texte du contrôle est présent, obligeant le développeur à utiliser l’action DomainUpDown.DownButton() sur le contrôle avant d’utiliser l’action DomainUpDown.UpButton(). À compter de .NET Framework 4.7.2, les actions DomainUpDown.UpButton() et DomainUpDown.DownButton() fonctionnent indépendamment dans ce scénario et restent synchronisées.

Suggestion

Une application doit s’exécuter sur .NET Framework 4.7.2 ou ultérieur pour tirer parti de ces changements. Pour que l’application bénéficie de ces changements, procédez de l’une des manières suivantes :

• Recompilez-la pour qu’elle cible .NET Framework 4.7.2. Ce changement est activé par défaut sur les applications Windows Forms qui ciblent .NET Framework 4.7.2 ou ultérieur.
• Refusez le comportement de défilement hérité en ajoutant le commutateur AppContext suivant à la section <runtime> du fichier de configuration de l’application et en lui affectant la valeur false, comme dans l’exemple suivant.

<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling=false"/>
</runtime>

Nom	Valeur
Étendue	Edge
Version	4.7.2
Type	Reciblage

API affectées

• DomainUpDown.UpButton()
• DomainUpDown.DownButton()

Windows Presentation Foundation (WPF)

Le focus clavier se déplace désormais correctement entre plusieurs couches d’hébergement WinForms/WPF

Détails

Imaginez une application WPF qui héberge un contrôle WinForms hébergeant à son tour des contrôles WPF. Les utilisateurs peuvent être dans l’impossibilité de quitter la couche WinForms au moyen de la touche Tab si le premier ou dernier contrôle dans cette couche est le contrôle WPF System.Windows.Forms.Integration.ElementHost. Ce changement résout ce problème, et les utilisateurs peuvent désormais quitter la couche WinForms au moyen de la touche Tab. Les applications automatisées pour lesquelles il est indispensable que le focus ne quitte jamais la couche WinForms pourraient ne plus fonctionner comme prévu.

Suggestion

Un développeur qui souhaite utiliser ce changement tout en ciblant une version du .NET Framework antérieure à la version 4.7.2 peut définir l’ensemble suivant d’indicateurs AppContext sur false pour activer la modification.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false"/>
</runtime>
</configuration>

Les applications WPF doivent accepter toutes les améliorations d’accessibilité antérieures pour obtenir les dernières améliorations. En d’autres termes, les deux commutateurs Switch.UseLegacyAccessibilityFeatures et Switch.UseLegacyAccessibilityFeatures.2 doivent être définis. Un développeur qui a besoin des fonctionnalités antérieures tout en ciblant .NET 4.7.2 ou version ultérieure peut définir l’indicateur AppContext suivant sur la valeur true pour activer la modification.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures.2=true"/>
</runtime>
</configuration>

Nom	Valeur
Étendue	Edge
Version	4.7.2
Type	Reciblage

L’algorithme de hachage par défaut pour le compilateur de balisage de WPF est désormais SHA256

Détails

Le compilateur de balisage de WPF fournit des services de compilation pour les fichiers de balisage XAML. Dans .NET Framework 4.7.1 et versions antérieures, l’algorithme de hachage par défaut utilisé pour les sommes de contrôle était SHA1. En raison des récents problèmes de sécurité avec SHA1, cette valeur par défaut est remplacée par SHA256 à compter de .NET Framework 4.7.2. Ce changement affecte toutes les générations de somme de contrôle pour les fichiers de balisage pendant la compilation.

Suggestion

Un développeur qui cible .NET Framework 4.7.2 ou version ultérieure et souhaite restaurer le comportement de hachage SHA1 doit définir l’indicateur AppContext suivant.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Markup.DoNotUseSha256ForMarkupCompilerChecksumAlgorithm=true"/>
</runtime>
</configuration>

Un développeur qui souhaite utiliser le hachage SHA256 tout en ciblant une version du .NET Framework antérieure à la version 4.7.2 doit définir l’indicateur AppContext ci-dessous. Notez que la version installée du .NET Framework doit être la version 4.7.2 ou une version ultérieure.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Markup.DoNotUseSha256ForMarkupCompilerChecksumAlgorithm=false"/>
</runtime>
</configuration>

Nom	Valeur
Étendue	Mode transparent
Version	4.7.2
Type	Reciblage

La gestion de l’arrêt de WPF AppDomain peut maintenant appeler dispatcher.Invoke dans le nettoyage des événements faibles

Détails

Dans .NET Framework 4.7.1 et versions antérieures, WPF crée potentiellement un System.Windows.Threading.Dispatcher sur le thread de finaliseur .NET lors de l’arrêt d’AppDomain. Ce problème a été résolu dans .NET Framework 4.7.2 et versions ultérieures en rendant le nettoyage des événements faibles sensible aux threads. De ce fait, WPF peut appeler Dispatcher.Invoke pour finaliser le processus de nettoyage. Dans certaines applications, cette modification liée à la synchronisation du finaliseur peut entraîner des exceptions pendant l’arrêt d’AppDomain ou du processus. Cela se produit généralement dans les applications qui ne ferment pas correctement les répartiteurs exécutés sur les threads de travail avant l’arrêt du processus ou d’AppDomain. Ces applications doivent gérer correctement la durée de vie des répartiteurs.

Suggestion

Dans .NET Framework 4.7.2 et versions ultérieures, les développeurs peuvent désactiver ce correctif afin d’atténuer (mais pas d’éliminer) les problèmes de synchronisation qui peuvent se produire en raison de la modification relative au nettoyage. Pour désactiver cette modification, utilisez l’indicateur AppContext suivant.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotInvokeInWeakEventTableShutdownListener=true"/>
</runtime>
</configuration>

Nom	Valeur
Étendue	Edge
Version	4.7.2
Type	Reciblage

WPF : Modification d’une clé primaire lors de l’affichage de données ADO dans un scénario maître/détail

Détails

Supposons que vous disposiez d’une collection ADO d’éléments de type Order, avec une relation nommée OrderDetails la reliant à une collection d’éléments de type Detail via la clé primaire OrderID. Dans votre application WPF, vous pouvez lier un contrôle de liste aux détails d’un ordre spécifique :

<ListBox ItemsSource="{Binding Path=OrderDetails}" >

où DataContext est un Order. WPF obtient la valeur de la propriété OrderDetails, une collection D de tous les éléments Detail dont la propriété OrderID correspond à la propriété OrderID de l’élément maître. Le changement de comportement se produit lorsque vous modifiez la clé primaire OrderID de l’élément maître. ADO modifie automatiquement le OrderID de chacun des enregistrements concernés dans la collection de détails (à savoir les enregistrements copiés dans la collection D). Qu'advient-il ensuite de la collection D ?

• Ancien comportement : la collection D est effacée. L’élément principal ne déclenche aucune notification de modification pour la propriété OrderDetails. La zone de liste continue d’utiliser la collection D, qui est maintenant vide.
• Nouveau comportement : la collection D reste inchangée. Chacun de ses éléments déclenche une notification de modification pour la propriété OrderID. La zone de liste continue d’utiliser la collection D et affiche les détails avec le nouveau OrderID. WPF implémente le nouveau comportement en créant la collection D d’une autre manière : en appelant la méthode ADO DataRowView.CreateChildView(DataRelation, Boolean) avec l’argument followParent défini sur true.

Suggestion

Une application obtient le nouveau comportement à l’aide du commutateur AppContext suivant.

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Windows.Data.DoNotUseFollowParentWhenBindingToADODataRelation=false"/>
  </runtime>
</configuration>

Le commutateur par défaut est true (ancien comportement) pour les applications qui ciblent .NET 4.7.1 ou version antérieure, et false (nouveau comportement) pour les applications qui ciblent .NET 4.7.2 ou version ultérieure.

Nom	Valeur
Étendue	Secondaire
Version	4.7.2
Type	Reciblage

Le visuel de focus WPF pour RadioButton et CheckBox s’affiche désormais correctement quand les contrôles n’ont pas de contenu

Détails

Dans .NET Framework 4.7.1 et versions antérieures, les contrôles WPF System.Windows.Controls.CheckBox et System.Windows.Controls.RadioButton ont des visuels de focus incohérents et, dans les thèmes standard et à contraste élevé, incorrects. Ces problèmes se produisent dans les cas où les contrôles n’ont pas de contenu défini. Cela peut rendre la transition entre les thèmes confuse et le visuel de focus difficile à voir. Dans .NET Framework 4.7.2, ces visuels sont désormais plus cohérents entre les thèmes et plus facilement visibles dans les thèmes classique et à contraste élevé.

Suggestion

Un développeur ciblant .NET Framework 4.7.2 qui souhaite restaurer le comportement de .NET 4.7.1 doit définir l’indicateur AppContext suivant.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures.2=true;"/>
</runtime>
</configuration>

Un développeur qui souhaite utiliser cette modification tout en ciblant une version de .NET Framework antérieure à la version 4.7.2 doit définir les indicateurs AppContext suivants. Notez que tous les indicateurs doivent être définis correctement et que la version installée de .NET Framework doit être la version 4.7.2 ou ultérieure. Les applications WPF doivent accepter toutes les améliorations d’accessibilité antérieures pour obtenir les dernières améliorations. Pour ce faire, vérifiez que les deux commutateurs AppContext Switch.UseLegacyAccessibilityFeatures et Switch.UseLegacyAccessibilityFeatures.2 sont définis sur false.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false;"/>
</runtime>
</configuration>

Nom	Valeur
Étendue	Edge
Version	4.7.2
Type	Reciblage

La sélection de texte WPF TextBox/PasswordBox ne suit pas les couleurs système

Détails

Dans .NET Framework 4.7.1 et versions antérieures, WPF System.Windows.Controls.TextBox et System.Windows.Controls.PasswordBox pouvaient afficher une sélection de texte uniquement dans la couche Ornement. Dans certains thèmes système, cela occultait le texte, au point de le rendre difficile à lire. Dans .NET Framework 4.7.2 et ultérieur, les développeurs ont la possibilité d’activer un schéma de rendu de sélection non basée sur la couche Ornement qui atténue ce problème.

Suggestion

Un développeur qui souhaite utiliser cette modification doit définir l’indicateur AppContext suivant de façon appropriée. Vous ne pouvez utiliser cette fonctionnalité que si vous avez installé .NET Framework version 4.7.2 ou ultérieure. Pour activer la sélection non basée sur un ornement, utilisez l’indicateur AppContext suivant.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Text.UseAdornerForTextboxSelectionRendering=false"/>
</runtime>
</configuration>

Nom	Valeur
Étendue	Edge
Version	4.7.2
Type	Reciblage

Windows Workflow Foundation (WF)

Éviter la récursivité infinie pour IWorkflowInstanceManagement.TransactedCancel et IWorkflowInstanceManagement.TransactedTerminate

Détails

Lorsque les API IWorkflowInstanceManagement.TransactedCancel ou IWorkflowInstanceManagement.TransactedTerminate sont utilisées pour annuler ou terminer une instance de service de workflow, il peut arriver que l’instance de workflow rencontre un dépassement de la capacité de la pile à cause d’une récursivité infinie si le runtime Workflow tente de conserver l’instance de service dans le cadre du traitement de la demande. Le problème se produit si l’instance de workflow est dans un état où elle attend qu’une autre requête WCF en suspens vers un autre service soit terminée. Les opérations TransactedCancel et TransactedTerminate créent des éléments de travail mis en file d’attente pour l’instance de service de workflow. Ces éléments de travail ne sont pas exécutés dans le cadre du traitement de la demande TransactedCancel/TransactedTerminate. Étant donné que l’instance de service de workflow attend que soit effectuée l’autre demande WCF en suspens, l’élément de travail créé reste dans la file d’attente. L’opération TransactedCancel/TransactedTerminate est effectuée, puis le contrôle est retourné au client. Lors de sa validation, la transaction associée à l’opération TransactedCancel/TransactedTerminate doit conserver l’état de l’instance de service de workflow. Toutefois, comme il existe une demande WCF en suspens pour l’instance, le runtime du workflow ne peut pas conserver l’instance de service de workflow, et une boucle de récursivité infinie entraîne le dépassement de la capacité de la pile. Étant donné que TransactedCancel et TransactedTerminate créent uniquement un élément de travail en mémoire, le fait qu’une transaction existe n’a aucun effet. Une restauration de la transaction n’abandonne pas l’élément de travail. Pour résoudre ce problème, à compter de .NET Framework 4.7.2, nous avons introduit un AppSetting qui peut être ajouté au fichier web.config/app.config du service de workflow qui lui indique d’ignorer les transactions pour TransactedCancel et TransactedTerminate. Cela permet à la transaction de valider sans attendre la persistance de l’instance de workflow. L’AppSetting pour cette fonctionnalité est nommé microsoft:WorkflowServices:IgnoreTransactionsForTransactedCancelAndTransactedTerminate. La valeur true indique que la transaction doit être ignorée, évitant ainsi le dépassement de la capacité de la pile. La valeur par défaut de cet AppSetting étant false, les instances de service de workflow existantes ne sont pas affectées.

Suggestion

Si vous utilisez AppFabric ou un autre client IWorkflowInstanceManagement et qu’un dépassement de la capacité de la pile se produit dans l’instance de service de workflow quand vous essayez d’annuler ou de terminer une instance de workflow, vous pouvez ajouter le code suivant à la section <appSettings> du fichier web.config/app.config du service de workflow :

<add key="microsoft:WorkflowServices:IgnoreTransactionsForTransactedCancelAndTransactedTerminate" value="true"/>

Si vous ne rencontrez pas ce problème, il est inutile d’effectuer cette opération.

Nom	Valeur
Étendue	Edge
Version	4.7.2
Type	Reciblage