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

Article
01/10/2025

Cet article répertorie les problèmes de compatibilité des applications qui ont été introduits dans .NET Framework 4.7, 4.7.1et 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 une T:System.NullReferenceException lors de la récupération d’une valeur P:System.Web.HttpRuntime.AppDomainAppPath qui inclut des caractères Null. Dans .NET Framework 4.6.1 et versions antérieures, le runtime lève une T:System.ArgumentNullException.

Suggestion

Vous pouvez effectuer l’une des opérations suivantes pour répondre à cette modification :

Gérez la T:System.NullReferenceException si vous exécutez l’application sur .NET Framework 4.6.2.
Effectuez une mise à niveau vers .NET Framework 4.7, qui restaure le comportement précédent et lève une T:System.ArgumentNullException.

Nom	Valeur
Portée	Microsoft Edge
Version	4.6.2
Type	Reciblage

API affectées

HttpRuntime.AppDomainAppPath

Limiter les requêtes simultanées par session

Détails

Dans .NET Framework 4.6.2 et versions antérieures, ASP.NET exécute les requêtes avec le même Sessionid de manière séquentielle et ASP.NET émet toujours le Sessionid via les cookies par défaut. Si une page prend beaucoup de temps pour répondre, elle dégrade considérablement les performances du serveur en appuyant sur F5 sur le navigateur. Dans le correctif, nous avons ajouté un compteur pour suivre les demandes mises en file d’attente et arrêter les requêtes lorsqu’elles dépassent une limite spécifiée. La valeur par défaut est 50. Si la limite est atteinte, un avertissement est consigné dans le journal des événements et une réponse HTTP 500 peut être enregistrée dans le journal IIS.

Proposition

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
Portée	Microsoft Edge
Version	4.7
Type	Reciblage

Réseautage

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

Détails

À compter des applications qui ciblent .NET Framework 4.7, la valeur par défaut de la propriété ServicePointManager.SecurityProtocol est SecurityProtocolType.SystemDefault. Cette modification permet aux API réseau .NET Framework basées sur SslStream (par exemple, 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 selon le système d’exploitation et toute configuration personnalisée effectuée 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 Protocoles dans TLS/SSL (SSP SCHANNEL).

Pour les applications qui ciblent une version antérieure du .NET Framework, la valeur par défaut de la propriété ServicePointManager.SecurityProtocol dépend de la version du .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

Cette modification affecte les applications qui ciblent .NET Framework 4.7 ou versions ultérieures. Si vous préférez utiliser un protocole défini plutôt que d’utiliser la valeur par défaut du système, vous pouvez définir explicitement la valeur de la propriété ServicePointManager.SecurityProtocol. Si cette modification n’est pas souhaitable, vous pouvez la désactiver en ajoutant un paramètre de configuration à la section <runtime> de votre fichier de configuration d’application. L’exemple suivant montre à la fois la section <runtime> et le commutateur d’opt-out Switch.System.Net.DontEnableSystemDefaultTlsVersions :

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

Nom	Valeur
Portée	Mineur
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 l'System.ComponentModel.Win32Exception peut être mappé à l’alerte TLS à partir de la partie distante à l’aide des codes d’erreur Schannel pour les alertes TLS et SSL. Pour plus d’informations, consultez RFC 2246 : Section 7.2.2 Alertes d’erreur.
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 appelant des API d’E/S réseau telles que Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32) doivent gérer IOException ou System.TimeoutException.
La fonctionnalité Alertes TLS est activée par défaut à partir de .NET Framework 4.7. Les applications ciblant les versions du .NET Framework de 4.0 à 4.6.2 exécutées sur un système .NET Framework 4.7 ou ultérieur auront la fonctionnalité désactivée pour préserver la compatibilité.
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 programme : doit être la première chose que l’application fait, car ServicePointManager ne s’initialise 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
Portée	Microsoft Edge
Version	4.7
Type	Reciblage

API affectées

Sécurité

CspParameters.ParentWindowHandle attend maintenant la valeur HWND

Détails

La valeur ParentWindowHandle, introduite dans le .NET Framework 2.0, permet à une application d'enregistrer un identificateur de fenêtre parente afin que toute interface utilisateur nécessaire pour accéder à la clé (par exemple, une boîte de dialogue de saisie de code PIN ou de consentement) s'ouvre comme une fenêtre modale enfant de la fenêtre spécifiée. À partir des applications ciblant le .NET Framework 4.7, une application Windows Forms peut définir la propriété ParentWindowHandle avec un code comme le suivant :

cspParameters.ParentWindowHandle = form.Handle;

Dans les versions précédentes du .NET Framework, la valeur était censée être une représentant un emplacement en mémoire où réside la valeur HWND . Définir la propriété sur le form.Handle en Windows 7 et versions antérieures n’avait aucun effet, mais en Windows 8 et versions ultérieures, cela entraîne un «System.Security.Cryptography.CryptographicException: le paramètre est incorrect ».

Suggestion

Les applications ciblant .NET Framework 4.7 ou version ultérieure souhaitant inscrire une relation de fenêtre parente sont encouragées à utiliser le formulaire simplifié :

cspParameters.ParentWindowHandle = form.Handle;

Les utilisateurs qui avaient identifié que la valeur correcte à passer était l’adresse d’un emplacement de mémoire qui contenait la valeur form.Handle pouvez désactiver le 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 opter pour le nouveau comportement sur le runtime .NET Framework 4.7 lorsque l’application se charge sous les anciennes versions de .NET Framework peuvent définir le commutateur AppContext sur false.

Nom	Valeur
Portée	Mineur
Version	4.7
Type	Reciblage

API affectées

CspParameters.ParentWindowHandle

SslStream prend en charge les alertes TLS

Détails

Suggestion

Par programme : doit être la première chose que l’application fait, car ServicePointManager ne s’initialise 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
Portée	Microsoft Edge
Version	4.7
Type	Reciblage

API affectées

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, le System.Runtime.Serialization.Json.DataContractJsonSerializer n’a pas sérialisé certains caractères de contrôle spéciaux, tels que \b, \f et \t, d’une manière compatible avec les normes ECMAScript V6 et V8. À compter 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 web.config :

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

Nom	Valeur
Portée	Microsoft Edge
Version	4.7
Type	Reciblage

API affectées

La sécurité des messages WCF est désormais en mesure d’utiliser TLS1.1 et TLS1.2

Détails

À compter du .NET Framework 4.7, les clients peuvent configurer TLS1.1 ou TLS1.2 dans la sécurité des messages WCF en plus de SSL3.0 et TLS1.0 via les paramètres de configuration de l’application.

Suggestion

Dans .NET Framework 4.7, la prise en charge de TLS1.1 et TLS1.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 web.config :

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

Nom	Valeur
Portée	Microsoft Edge
Version	4.7
Type	Reciblage

Windows Presentation Foundation (WPF)

Les appels à System.Windows.Input.PenContext.Disable sur les systèmes tactiles peuvent provoquer une 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 .NET Framework 4.7. Pour empêcher l’exception, effectuez une mise à niveau vers une version du .NET Framework à partir de .NET Framework 4.7.

Nom	Valeur
Portée	Microsoft Edge
Version	4.6.1
Type	Reciblage

NullReferenceException dans le code de gestion des exceptions provenant de ImageSourceConverter.ConvertFrom

Détails

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

Par défaut, toutes les applications ciblant .NET Framework 4.6.2 et versions antérieures continuent de générer des exceptions System.NullReferenceException pour des raisons de compatibilité. Les développeurs ciblant .NET Framework 4.7 et versions ultérieures doivent voir les exceptions appropriées.

Suggestion

Les développeurs qui souhaitent revenir à l'obtention de System.NullReferenceException lorsqu'ils ciblent .NET Framework 4.7 ou une version ultérieure 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
Portée	Microsoft 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 que Grid utilise pour allouer de l’espace aux *-colonnes. Cela modifie la largeur réelle affectée aux *-colonnes dans un certain nombre de 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 explicitement qu’à 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 produites par l’ancien algorithme ; dans le dernier cas, la différence sera au plus un ou deux pixels.

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

L’allocation totale aux colonnes peut dépasser la largeur de la grille. Cela peut se produire lors de l’allocation d’espace à une colonne dont le partage proportionnel est inférieur à sa taille minimale. L’algorithme alloue la taille minimale, ce qui réduit l’espace disponible pour d’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 plus légère de #1/#2, résultant de l'allocation aux colonnes * A, B et C (dans cet ordre), où la part proportionnelle de B enfreint sa contrainte minimale (ou maximale). Comme ci-dessus, cela modifie l’espace disponible pour la colonne C, qui obtient moins (ou plus) d’allocation proportionnelle que A.
Les colonnes avec des poids extrêmement importants (> 10^298) sont toutes 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 plus petits) ne sont pas respectées.
Les colonnes avec des pondérations infinies ne sont pas gérées correctement. (En fait, vous ne pouvez pas définir un poids sur Infini, mais il s’agit d’une restriction artificielle. Le code d’allocation essayait de le gérer, mais il faisait un mauvais travail.)
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ées 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 précis, si deux colonnes sont déclarées respectivement avec largeur x* et y* et si aucune colonne ne reçoit sa largeur minimale ou maximale, les largeurs réelles v et w affectées aux colonnes sont dans la même proportion : 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). Cela peut être égal à zéro, par exemple si la somme des largeurs minimales dépasse la largeur disponible de la grille.
- Toutes ces instructions doivent être interprétées par rapport à la disposition « idéale ». Lorsque l’arrondi de disposition est activé, la largeur réelle peut différer de la largeur idéale jusqu’à un pixel.

Remarque

Tout ce qui a été dit sur les colonnes et les largeurs de cet article s’applique également aux lignes et aux hauteurs.

Suggestion

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

Pour remplacer la valeur par défaut, utilisez le paramètre de configuration suivant :

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

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

Nom	Valeur
Portée	Mineur
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 support pour l'encrage 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époser n’affiche pas la rétroaction appropriée pour 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 entraîner l’arrêt de la réponse 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 leur application :

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

La suppression de cette valeur ou la définition de la valeur false désactive cette pile facultative. Notez que cette pile est disponible uniquement sur Windows 10 Creators Update et versions ultérieures.

Nom	Valeur
Portée	Microsoft 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 du .NET Framework 4.7, l’algorithme est SHA1. Si votre code a rendu persistant ces sommes de contrôle, elles seront incompatibles.

Une 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
Portée	Mineur
Version	4.7
Type	Reciblage

.NET Framework 4.7.1

ASP.NET

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

Détails

À compter de .NET Framework 4.7.1, ASP.NET a amélioré la façon dont ASP.NET contrôles web fonctionnent avec la technologie d’accessibilité dans Visual Studio pour mieux prendre en charge les clients ASP.NET. Il s’agit notamment des modifications suivantes :

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.
Modifications pour améliorer l’affichage en mode Contraste élevé, comme l’éditeur de champs du pagineur de données.
Modifications permettant d'améliorer l'expérience de navigation au clavier pour les contrôles, comme la boîte de dialogue Champs dans l'assistant Modifier les champs de page du contrôle DataPager, la boîte de dialogue Configurer ObjectContext ou la boîte de dialogue Configurer la sélection des données dans l'assistant Configurer la source de données.

Suggestion

Comment activer ou désactiver ces modifications Pour que le Concepteur Visual Studio bénéficie de ces modifications, il doit s’exécuter sur .NET Framework 4.7.1 ou version ultérieure. L’application web peut tirer parti de ces modifications de l’une des manières suivantes :

Installez Visual Studio 2017 15.3 ou version ultérieure, qui prend en charge les nouvelles fonctionnalités d’accessibilité avec le commutateur AppContext suivant par défaut.
Désactivez les comportements d’accessibilité hérités en ajoutant le commutateur AppContext Switch.UseLegacyAccessibilityFeatures à la section <runtime> du fichier devenv.exe.config et en le définissant sur false, comme l’illustre 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>

Nom	Valeur
Portée	Mineur
Version	4.7.1
Type	Reciblage

Principal

Exceptions de thread d’arrière-plan SerialPort

Détails

Les threads d’arrière-plan créés avec les flux SerialPort ne terminent plus le processus lorsqu'une exception du système d'exploitation est déclenchée.
Dans les applications qui ciblent le .NET Framework 4.7 et les versions antérieures, un processus est interrompu lorsqu'une exception du système d'exploitation est déclenché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 les événements de système d’exploitation liés au port série actif et peuvent se bloquer 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 si elle n’est pas souhaitable en ajoutant ce qui suit à 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 version ultérieure, vous pouvez choisir de gérer les exceptions en ajoutant les éléments suivants à la section <runtime> de votre fichier app.config :

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

Nom	Valeur
Portée	Mineur
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 versions antérieures, 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 des exceptions à ServiceBase.Run pour les services qui ne parviennent pas à démarrer.

Suggestion

Au démarrage du service, s’il existe une exception, cette exception est propagée. Cela doit aider à diagnostiquer les cas où les services ne parviennent pas à démarrer.

Si ce comportement n’est pas souhaitable, vous pouvez le désactiver en ajoutant l’élément AppContextSwitchOverrides suivant à la section runtime de votre fichier de configuration d’application :

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

Si votre application cible une version antérieure à la version 4.7.1, mais que vous souhaitez 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
Portée	Mineur
Version	4.7.1
Type	Reciblage

API affectées

Sécurité

Algorithmes SignedXML et SignedXMS par défaut modifiés en SHA256

Détails

Dans .NET Framework 4.7 et versions antérieures, SignedXML et SignedCMS sont par défaut sha1 pour certaines opérations. À compter du .NET Framework 4.7.1, SHA256 est activé par défaut pour ces opérations. Cette modification est nécessaire, car SHA1 n’est plus considéré comme sécurisé.

Suggestion

Il existe deux nouvelles valeurs de commutateur de contexte pour 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 restaurer la valeur par défaut sur SHA1 en ajoutant le commutateur de configuration suivant au runtime section de votre fichier de configuration d’application :

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

Pour les applications qui ciblent .NET Framework 4.7 et versions antérieures, vous pouvez opter pour cette modification en ajoutant le commutateur de configuration suivant au runtime section du fichier de configuration de votre application :

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

Nom	Valeur
Portée	Mineur
Version	4.7.1
Type	Reciblage

API affectées

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

Détails

À compter du .NET Framework 4.6.2, le type concret de l’objet retourné par la méthode SignedXml.GetPublicKey a changé (sans quirk) d’une implémentation CryptoServiceProvider à une implémentation Cng. Cela est dû au fait que l’implémentation est passée de l’utilisation de certificate.PublicKey.Key à l’utilisation du certificate.GetAnyPublicKey interne qui passe à RSACertificateExtensions.GetRSAPublicKey.

Suggestion

À compter des applications exécutées 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 au runtime runtime section de votre fichier de configuration d’application :

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

Nom	Valeur
Portée	Microsoft 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 Kit de développement logiciel (SDK) .NET

Détails

Dans le SDK .NET Framework 4.7.1, les outils SvcConfigEditor.exe et SvcTraceViewer.exe ont été améliorés en corrigeant divers problèmes d’accessibilité. La plupart de ces problèmes étaient petits comme un nom qui n’est pas défini ou certains modèles d’automatisation de l’interface utilisateur ne sont pas implémentés correctement. Bien que de nombreux utilisateurs ne sachent pas ces valeurs incorrectes, les clients qui utilisent des technologies d’assistance telles que les lecteurs d’écran trouveront ces outils sdk plus accessibles. Certes, ces correctifs modifient certains comportements précédents, comme l’ordre du focus clavier. Pour obtenir tous les correctifs d’accessibilité dans ces outils, vous pouvez effectuer les opérations suivantes dans votre fichier app.config :

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

Nom	Valeur
Portée	Microsoft Edge
Version	4.7.1
Type	Reciblage

Windows Forms

Améliorations de l’accessibilité dans les contrôles Windows Forms

Détails

Windows Forms améliore son fonctionnement avec les technologies d’accessibilité pour mieux prendre en charge les clients Windows Forms. Les modifications suivantes commencent par .NET Framework 4.7.1 :

Modifications pour améliorer l’affichage en mode Contraste élevé.
Modifications pour améliorer l’expérience du navigateur de propriétés. Les améliorations apportées au navigateur de propriétés sont les suivantes :
Meilleure navigation au clavier dans les différentes fenêtres de sélection déroulante.
Une réduction des taquets de tabulation inutiles.
Meilleure création de rapports sur les types de contrôle.
Comportement du Narrateur amélioré.
Modifications apportées à l’implémentation de modèles d’accessibilité d’interface utilisateur manquants dans les contrôles.

Suggestion

Comment accepter ou refuser ces modifications Pour que l’application bénéficie de ces modifications, elle doit s’exécuter sur .NET Framework 4.7.1 ou version ultérieure. L’application peut tirer parti de ces modifications de l’une des manières suivantes :

Il est recompilé pour cibler le .NET Framework 4.7.1. Ces modifications d’accessibilité sont activées par défaut sur les applications Windows Forms qui ciblent .NET Framework 4.7.1 ou version ultérieure.
Il désactive les comportements d’accessibilité hérités en ajoutant le commutateur AppContext suivant à la section <runtime> du fichier app.config et en le définissant sur false, comme l’illustre 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>

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 de nouvelles fonctionnalités d’accessibilité WinForms à l’aide de modèles d’appel courants, publiquement décrits. 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 prend en charge les modèles et propriétés d’automatisation d’interface utilisateur 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 dans la boîte de dialogue d’erreur qui s’affiche lorsque l’utilisateur saisit une valeur incorrecte dans le contrôle prend en charge le modèleDévelopper/Réduire , les notifications de changement d'état et de nom, ainsi qu'une propriété ControlType avec une valeur de .
Le volet des messages, qui s'affiche lorsque le bouton Détails de la boîte de dialogue d'erreur est déplié, est désormais accessible au clavier et permet au Narrateur d’annoncer le contenu du message d’erreur.
Le AccessibleRole des lignes dans le contrôle PropertyGrid est passé de « Row » à « Cell ». La cellule est mappée à UIA ControlType « 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 de contrôle PropertyGrid qui représentent des éléments d’en-tête lorsque le contrôle PropertyGrid a une propriété PropertySort définie sur PropertySort.Categorized prennent en charge le modèle Développer/Réduire.
Amélioration de la navigation au clavier entre la grille et la barre des outils au-dessus de celle-ci. Appuyez sur « Maj-Tab » pour sélectionner maintenant le premier bouton ToolBar, au lieu de l’ensemble de la barre des outils.
Les contrôles PropertyGrid affichés en mode Contraste élevé dessinent désormais un rectangle de mise en surbrillance autour du bouton de la barre d’outils qui correspond à la valeur actuelle de la propriété PropertySort.
Les contrôles PropertyGrid affichés en mode Contraste élevé, et avec une propriété PropertySort définie sur PropertySort.Categorized, affichent désormais l’arrière-plan des en-têtes de catégorie de façon 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 d’un changement de contraste élevé et d’une modification pour les scénarios sans contraste élevé.
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 de couleurs définies par le système d’exploitation dans les thèmes à contraste élevé

Les contrôles Button et CheckBox avec leur propriété FlatStyle définie sur FlatStyle.System, qui est le style par défaut, utilisent désormais des couleurs définies par le système d’exploitation dans le thème Contraste élevé lorsque cette option est sélectionnée. Auparavant, les couleurs de texte et d’arrière-plan n’étaient pas contrastées et étaient difficiles à lire.
Les contrôles Button, CheckBox, RadioButton, Label, LinkLabelet GroupBox, avec leur propriété Enabled définie sur false, ont employé une couleur ombrée pour afficher du texte dans des thèmes à contraste élevé, ce qui a entraîné un faible contraste par rapport à l’arrière-plan. À présent, ces contrôles utilisent 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 sur une valeur autre que FlatStyle.System. Les derniers contrôles sont rendus par le système d’exploitation.
DataGridView affiche désormais un rectangle visible autour du contenu de la cellule qui a le focus actuel. Auparavant, cela n’était pas visible dans certains thèmes à contraste élevé.
Les contrôles ToolStripMenuItem dont la propriété Enabled a la valeur 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 : Windows 10 a changé de valeurs pour certaines couleurs système à contraste élevé. Windows Forms Framework est basé sur l’infrastructure Win32. Pour une expérience optimale, exécutez la dernière version de Windows et optez pour les dernières modifications 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

Lorsqu’un contrôle ComboBox a sa propriété DropDownStyle définie sur ComboBoxStyle.DropDownList et est le premier contrôle dans l’ordre de tabulation du formulaire, il affiche désormais un rectangle de focus lorsque le formulaire parent est ouvert à l’aide du clavier. Avant cette modification, le focus du clavier était sur ce contrôle, mais un indicateur de mise au point n'était pas affiché.

Prise en charge améliorée du Narrateur

Le contrôle MonthCalendar prend désormais en charge les technologies d’assistance pour accéder au contrôle, notamment en permettant au Narrateur de lire la valeur du contrôle, ce qu'il ne pouvait pas faire auparavant.
Le contrôle CheckedListBox avertit désormais le Narrateur lorsqu’une propriété CheckBox.CheckState a été modifiée. Auparavant, le Narrateur n’a pas reçu de notification et, par conséquent, les utilisateurs ne seraient pas informés que la propriété CheckState avait été mise à jour.
Le contrôle LinkLabel notifie le Narrateur du texte présent dans le contrôle de manière différente. Auparavant, le Narrateur a annoncé ce texte deux fois et lu «&» symboles en tant que texte réel, même s’ils ne sont pas visibles par un utilisateur. Le texte dupliqué a été supprimé des annonces du Narrateur, ainsi que les symboles «&» inutiles.
Les types de contrôle DataGridViewCell signalent maintenant 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. Auparavant, le Narrateur n’a pas pu se concentrer sur les éléments de menu désactivés pour lire le contenu.

Nom	Valeur
Portée	Majeur
Version	4.8
Type	Reciblage

API affectées

Windows Presentation Foundation (WPF)

Améliorations de l’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.
Le texte dans CheckBox et les contrôles RadioButton lorsqu’ils sont sélectionnés sont désormais plus faciles à voir que dans les versions précédentes du .NET Framework.
La bordure d’un ComboBox désactivé est désormais 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 ciblés utilisent désormais la couleur de thème appropriée. Dans les versions précédentes de .NET Framework, elles ne l’ont pas fait.
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 des couleurs de thème. Dans les versions précédentes de .NET Framework, elle n’a pas été prise en compte.
Le style de lien hypertexte par défaut passe maintenant à la couleur de thème correcte au survol de la souris. Dans les versions précédentes de .NET Framework, elle n’a pas été prise en compte.
La mise au point du 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, elle n’a pas été prise en compte.
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 de l’interaction du lecteur d’écran

Les contrôles Expander sont maintenant correctement annoncés comme groupes (développer/réduire) par les lecteurs d’écran.
Les éléments de contrôle DataGridCell sont désormais correctement annoncés en tant que cellules de tableau de données (localisées) par les lecteurs d’écran.
Les lecteurs d’écran annoncent désormais le nom d’un ComboBox modifiable.
Les contrôles PasswordBox ne sont plus annoncés comme aucun élément dans la vue par les lecteurs d’écran.

Support de LiveRegion

Les lecteurs d’écran, tels que le Narrateur, aident les utilisateurs à comprendre 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 d’interface utilisateur change quelque part dans l’écran et qu’il n’a pas le focus, l’utilisateur peut ne pas être informé et manquer des informations importantes. LiveRegions sont destinés à résoudre ce problème. Un développeur peut les utiliser pour informer le lecteur d’écran ou tout autre client ui Automation qu’une modification importante a été apportée à 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 permet également au lecteur d’écran de savoir combien il est important d’informer l’utilisateur de la modification apportée à l’interface utilisateur.

Suggestion

Comment accepter ou refuser ces modifications

Pour que l’application bénéficie de ces modifications, elle doit s’exécuter sur .NET Framework 4.7.1 ou version ultérieure. L’application peut tirer parti de ces modifications de l’une des manières suivantes :

Ciblez le .NET Framework 4.7.1. Il s’agit de l’approche recommandée. Ces modifications d’accessibilité sont activées par défaut sur les applications WPF qui ciblent .NET Framework 4.7.1 ou version ultérieure.

Il désactive les comportements d’accessibilité hérités en ajoutant le AppContext Switch suivant dans la section du fichier de configuration de l’application et en le définissant sur , comme l’illustre 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>

Les applications qui ciblent .NET Framework 4.7.1 ou version ultérieure et qui souhaitent conserver le comportement d’accessibilité hérité peuvent choisir d’utiliser les fonctionnalités d’accessibilité héritées en définissant explicitement ce commutateur AppContext sur true. Pour obtenir une vue d’ensemble de l’automatisation de l’interface utilisateur, consultez Vue d’ensemble d’UI Automation.

Nom	Valeur
Portée	Majeur
Version	4.7.1
Type	Reciblage

API affectées

É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, lorsque sa sélection change. Cela rend la propriété SelectedValue cohérente avec les autres propriétés de sélection (SelectedItem et SelectedIndex), qui sont mises à jour avant de déclencher l’événement.

Dans .NET Framework 4.7 et versions antérieures, la mise à jour de SelectedValue s’est produite avant l’événement dans la plupart des cas, mais elle s’est produite après l’événement si la modification de la sélection a été provoquée par la modification de la propriété SelectedValue.

Suggestion

Les applications qui ciblent .NET Framework 4.7.1 ou version ultérieure peuvent refuser cette modification et utiliser le comportement hérité en ajoutant ce qui suit à la section <runtime> du fichier de configuration de l’application :

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

Les applications qui ciblent .NET Framework 4.7 ou une version antérieure, mais qui s’exécutent sur .NET Framework 4.7.1 ou version ultérieure 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
Portée	Mineur
Version	4.7.1
Type	Reciblage

API affectées

É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, lorsque sa sélection change. Dans .NET Framework 4.7 et versions antérieures, la mise à jour de SelectedContent s’est produite après l’événement.

Suggestion

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

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

Nom	Valeur
Portée	Mineur
Version	4.7.1
Type	Reciblage

API affectées

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

Détails

Le System.IO.Packaging.PackageDigitalSignatureManager fournit des fonctionnalités pour les signatures numériques par rapport aux packages WPF. Dans .NET Framework 4.7 et versions antérieures, l’algorithme par défaut (PackageDigitalSignatureManager.DefaultHashAlgorithm) utilisé pour signer des parties d’un package était SHA1. En raison de problèmes de sécurité récents avec SHA1, cette valeur par défaut a été modifiée en SHA256 à partir du .NET Framework 4.7.1. Cette modification affecte toutes les signatures de package, y compris les documents XPS.

Suggestion

Un développeur qui souhaite utiliser cette modification tout en ciblant une version du framework inférieure à .NET Framework 4.7.1 ou un développeur qui a besoin des fonctionnalités précédentes lors du ciblage de .NET Framework 4.7.1 ou version ultérieure peut définir correctement l’indicateur AppContext suivant. Une valeur true entraîne l’utilisation de SHA1 comme algorithme par défaut ; false aboutit à SHA256.

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

Nom	Valeur
Portée	Microsoft 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 les modifications suivantes :

L’ordre de tabulation est modifié en 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
Fenêtre de définition de contenu pour les activités Receive, Send, SendReplyet ReceiveReply
D’autres fonctions sont disponibles via le clavier :
Lors de la modification des propriétés d’une activité, les groupes de propriétés peuvent être réduits par clavier la première fois qu’ils sont concentrés.
Les icônes d’avertissement sont désormais accessibles par clavier.
Le bouton Autres propriétés de la fenêtre Propriétés est désormais accessible par 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.
Visibilité améliorée des éléments avec focus, par exemple quand :
Ajout de lignes à 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 des valeurs par défaut pour les variables ou arguments
Les lecteurs d’écran peuvent désormais reconnaître correctement :
Points d’arrêt définis dans le concepteur de flux de travail.
Activités FlowSwitch<T>, FlowDecisionet CorrelationScope.
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.
Menus contextuels (clic droit) pour les activités.
Les éditeurs de valeurs de propriété, le bouton Effacer la recherche, les boutons Par catégorie et le tri alphabétique, ainsi que la boîte de dialogue Éditeur d’expressions dans la grille des propriétés.
Pourcentage de zoom dans le Concepteur de flux de travail.
Le séparateur dans les activités Parallel et Pick.
L’activité InvokeDelegate.
Fenêtre Sélectionner des 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 dans la visibilité du Concepteur de flux de travail et ses contrôles, tels que de meilleurs rapports de contraste entre les éléments et des zones de sélection plus visibles utilisées pour les éléments de focus.

Suggestion

Si vous disposez d’une application avec un concepteur de workflow réhébergé, votre application peut tirer parti de ces modifications en effectuant l’une ou l’autre de ces actions :

Recompilez votre application pour cibler .NET Framework 4.7.1. Ces modifications d’accessibilité sont activées par défaut.
Si votre application cible le .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 définir ce paramètre sur false, comme l’illustre 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>

Nom	Valeur
Portée	Mineur
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 spécifier l’orientation du texte. Dans les versions précédentes du .NET Framework, ces caractères ont été supprimés incorrectement de toutes les URI, même s’ils étaient présents dans leur forme codée en pourcentage. Pour mieux suivre RFC 3987, nous allons maintenant autoriser ces caractères dans les URI. Lorsqu’elles sont non codées dans un URI, elles sont encodées 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 de .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 cette modification n’est pas souhaitable, vous pouvez la désactiver en ajoutant le commutateur AppContextSwitchOverrides à la section <runtime> du fichier de configuration de l’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 sous des versions commençant par .NET Framework 4.7.2, 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 de l'application :

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

Nom	Valeur
Portée	Mineur
Version	4.7.2
Type	Reciblage

API affectées

System.Uri

DeflateStream utilise des API natives pour la décompression

Détails

À compter du .NET Framework 4.7.2, l’implémentation de la décompression dans la classe T:System.IO.Compression.DeflateStream a changé pour utiliser les API Windows natives par défaut. En règle générale, cela entraîne une amélioration substantielle des performances. Toutes les applications .NET ciblant .NET Framework version 4.7.2 ou ultérieure utilisent l’implémentation native. Cette modification peut entraîner des différences de comportement, notamment :

Les messages d’exception peuvent être différents. Toutefois, le type d’exception levée reste le même.
Certaines situations spéciales, telles que l’absence de mémoire suffisante pour terminer une opération, peuvent être gérées différemment.
Il existe des différences connues pour l’analyse de l’en-tête gzip (remarque : seule GZipStream définie pour la décompression est affectée) :
Les exceptions lors de l'analyse d'en-têtes non valides peuvent survenir à des moments différents.
L’implémentation native impose que les valeurs pour certains indicateurs réservés à l’intérieur de l’en-tête gzip (c’est-à-dire, FLG) soient définies conformément à la spécification, ce qui peut entraîner le lancement d’une exception là où auparavant les valeurs non valides étaient ignorées.

Suggestion

Si la décompression avec les API natives a affecté négativement le comportement de votre application, vous pouvez désactiver cette fonctionnalité en ajoutant le commutateur Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression à la section runtime de votre fichier app.config et en la 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
Portée	Mineur
Version	4.7.2
Type	Reciblage

API affectées

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

Détails

Dans System.Uri, certains caractères encodés en pourcentage, qui étaient parfois décodés, restent désormais toujours encodés. Cela se produit dans les propriétés et méthodes qui accèdent aux composants chemin, requête, fragment ou userinfo de l’URI. Le comportement ne change que lorsque les deux éléments suivants sont vrais :

L’URI contient la forme encodée de l’un des caractères réservés suivants : :, ', (, ), ! ou *.
L’URI contient un caractère Unicode ou encodé non réservé. Si les deux éléments ci-dessus sont vrais, les caractères réservés encodés restent encodés. Dans les versions précédentes du .NET Framework, elles sont décodées.

Suggestion

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

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

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

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

Nom	Valeur
Portée	Mineur
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é, il ne charge pas l’entrée par défaut.

Suggestion

Les utilisateurs resgen qui nécessitent le chargement d’une entrée au format binaire à partir d’emplacements non approuvés peuvent supprimer la marque web du fichier d’entrée ou appliquer le quirk de désabonnement. 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
Portée	Microsoft 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 à .NET Framework 4.7.2, les informations de fichier source et de ligne ne sont pas disponibles lors de l’utilisation de fichiers PDF portables, même si elles sont explicitement demandées.

Suggestion

Pour les applications qui ciblent le .NET Framework 4.7.2, vous pouvez désactiver le fichier source et les informations de ligne lors de l’utilisation de fichiers PDB portables si cela n'est pas souhaité en ajoutant les éléments suivants à 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 du .NET Framework, mais qui s’exécutent sur .NET Framework 4.7.2 ou version ultérieure, vous pouvez choisir d’accéder au fichier source et aux informations de ligne lors de l’utilisation des fichiers PDF portables en ajoutant les éléments suivants à la section <runtime> de votre fichier app.config :

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

Nom	Valeur
Portée	Microsoft Edge
Version	4.7.2
Type	Reciblage

API affectées

Windows Forms

Améliorations de l’accessibilité dans les contrôles Windows Forms pour .NET 4.7.2

Détails

Windows Forms Framework améliore son fonctionnement avec les technologies d’accessibilité pour mieux prendre en charge les clients Windows Forms. Il s’agit notamment des modifications suivantes :

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

Suggestion

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

Il est recompilé pour cibler le .NET Framework 4.7.2. Ces modifications d’accessibilité sont activées par défaut sur les applications Windows Forms qui ciblent .NET Framework 4.7.2 ou version ultérieure.
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 choisir les fonctionnalités d’accessibilité ajoutées dans .NET Framework 4.7.2, vous devez également opter pour les fonctionnalités d’accessibilité de .NET Framework 4.7.1. Les applications qui ciblent .NET Framework 4.7.2 ou version ultérieure et qui souhaitent conserver le comportement d’accessibilité hérité peuvent choisir d’utiliser les fonctionnalités d’accessibilité héritées en définissant explicitement ce commutateur AppContext sur true.

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

La flèche déroulante du ToolStripDropDownButton utilise désormais des couleurs définies par le système d’exploitation dans le thème Contraste élevé.
Les contrôles Button, RadioButton et CheckBox, avec FlatStyle défini sur FlatStyle.Flat ou FlatStyle.Popup, utilisent désormais des couleurs définies par le système d’exploitation dans le thème à contraste élevé lorsqu’ils sont sélectionnés. Auparavant, les couleurs de texte et d’arrière-plan n’étaient pas contrastées et étaient difficiles à lire.
Les contrôles contenus dans un GroupBox dont la propriété Enabled est définie sur false utiliseront désormais des couleurs définies par le système d’exploitation dans le thème Contraste élevé.
Les contrôles ToolStripButton, ToolStripComboBoxet ToolStripDropDownButton ont un rapport de contraste de luminosité accru en mode contraste élevé.
DataGridViewLinkCell utilisera par défaut des couleurs définies par le système d’exploitation en mode Contraste élevé pour la propriété DataGridViewLinkCell.LinkColor. REMARQUE : Windows 10 a changé de valeurs pour certaines couleurs système à contraste élevé. Windows Forms Framework est basé sur l’infrastructure Win32. Pour une expérience optimale, exécutez la dernière version de Windows et optez pour les dernières modifications 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}" />

Prise en charge améliorée 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é de DataGridView

Les lignes d’un DataGridView peuvent maintenant être triées à l’aide du clavier. À présent, un utilisateur peut utiliser la touche F3 pour trier par la colonne active.
Lorsque DataGridView.SelectionMode est définie sur DataGridViewSelectionMode.FullRowSelect, l’en-tête de colonne change de couleur pour indiquer la colonne actuelle au fur et à mesure que l'utilisateur navigue dans les cellules de la ligne actuelle.
La propriété DataGridViewCell.DataGridViewCellAccessibleObject.Parent retourne désormais le contrôle parent approprié.

Repères visuels améliorés

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

Prise en charge améliorée de la grille des 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 de contrôle PropertyGrid retournent désormais une false pour la propriété IsEnabledProperty uniquement lorsqu’un élément PropertyGrid peut être modifié 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 autorise désormais le focus lorsqu’il est contenu dans un ToolStripPanel dont la propriété TabStop a la valeur true.

Nom	Valeur
Portée	Majeur
Version	4.7.2
Type	Reciblage

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

Détails

Dans .NET Framework 4.7.1 et les versions précédentes, la propriété ContextMenuStrip.SourceControl retourne incorrectement null lorsque l’utilisateur ouvre le menu à partir de contrôles ToolStripMenuItem imbriqués. Dans le .NET Framework 4.7.2 et les versions ultérieures, la propriété SourceControl est toujours affectée au contrôle de code source.

Suggestion

Comment accepter ou refuser ces modifications Pour qu’une application bénéficie de ces modifications, elle doit s’exécuter sur .NET Framework 4.7.2 ou version ultérieure. L’application peut tirer parti de ces modifications de l’une des manières suivantes :

Elle cible le .NET Framework 4.7.2. Cette modification est activée par défaut sur les applications Windows Forms qui ciblent .NET Framework 4.7.2 ou version ultérieure.
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>

Les applications qui ciblent .NET Framework 4.7.2 ou version ultérieure et qui souhaitent conserver le comportement hérité peuvent choisir d’utiliser la valeur de contrôle de code source héritée en définissant explicitement ce commutateur AppContext sur true.

Nom	Valeur
Portée	Microsoft Edge
Version	4.7.2
Type	Reciblage

API affectées

ContextMenuStrip.SourceControl

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

Détails

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

Suggestion

Il est recompilé pour cibler le .NET Framework 4.7.2. Cette modification est activée par défaut sur les applications Windows Forms qui ciblent .NET Framework 4.7.2 ou version ultérieure.
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>

Les applications qui ciblent .NET Framework 4.7.2 ou version ultérieure et qui souhaitent conserver le comportement hérité peuvent choisir de ne pas libérer les ressources de police en définissant explicitement ce commutateur AppContext sur true.

Nom	Valeur
Portée	Microsoft Edge
Version	4.7.2
Type	Reciblage

API affectées

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 du .NET Framework 4.7.2, les actions DomainUpDown.UpButton() et DomainUpDown.DownButton() fonctionnent indépendamment dans ce scénario et restent synchronisées.

Suggestion

Pour qu’une application bénéficie de ces modifications, elle doit s’exécuter sur .NET Framework 4.7.2 ou version ultérieure. L’application peut tirer parti de ces modifications de l’une des manières suivantes :

Il est recompilé pour cibler le .NET Framework 4.7.2. Cette modification est activée par défaut sur les applications Windows Forms qui ciblent .NET Framework 4.7.2 ou version ultérieure.
Il désactive le comportement de défilement hérité en ajoutant le commutateur AppContext suivant à la section du fichier de configuration de l’application et en le définissant sur , comme l’illustre l’exemple suivant.

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

Nom	Valeur
Portée	Microsoft Edge
Version	4.7.2
Type	Reciblage

API affectées

Windows Presentation Foundation (WPF)

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

Détails

Considérez une application WPF hébergeant un contrôle WinForms qui héberge à 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 cette modification tout en ciblant une version du framework antérieure à .NET 4.7.2 peut définir l’ensemble suivant d’indicateurs AppContext sur false pour que la modification soit activée.

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

Les applications WPF doivent opter pour toutes les améliorations précoces de l’accessibilité pour obtenir les améliorations ultérieures. En d’autres termes, les commutateurs Switch.UseLegacyAccessibilityFeatures et Switch.UseLegacyAccessibilityFeatures.2 doivent être définis par le développeur A qui nécessite la fonctionnalité précédente lors du ciblage de .NET 4.7.2 ou version ultérieure peut définir l’indicateur AppContext suivant sur true pour que la modification soit désactivée.

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

Nom	Valeur
Portée	Microsoft Edge
Version	4.7.2
Type	Reciblage

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

Détails

WPF MarkupCompiler 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 de problèmes de sécurité récents avec SHA1, cette valeur par défaut a été modifiée en SHA256 à partir du .NET Framework 4.7.2. Cette modification 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 revenir au 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 framework antérieure à .NET 4.7.2 doit définir l’indicateur AppContext ci-dessous. Notez que la version installée du .NET Framework doit être 4.7.2 ou ultérieure.

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

Nom	Valeur
Portée	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. Cela a été corrigé dans .NET Framework 4.7.2 et les versions ultérieures, en rendant le nettoyage des événements faibles compatible avec les threads. En raison de cela, WPF peut appeler Dispatcher.Invoke pour terminer le processus de nettoyage. Dans certaines applications, cette modification du minutage du finaliseur peut entraîner des exceptions lors de 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 en cours d’exécution sur les threads de travail avant l’arrêt du processus ou d’AppDomain. Ces applications doivent prendre soin de 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 minutage qui peuvent se produire en raison du changement de nettoyage. Pour désactiver la modification dans le nettoyage, utilisez l’indicateur AppContext suivant.

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

Nom	Valeur
Portée	Microsoft Edge
Version	4.7.2
Type	Reciblage

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

Détails

Supposons que vous disposez d’une collection ADO d’éléments de type Order, avec une relation nommée « OrderDetails » associée à 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 donné :

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

où DataContext est un Order. WPF obtient la valeur de la propriété OrderDetails : collection D de tous les éléments Detail dont la OrderID correspond au 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 la OrderID de chacun des enregistrements affectés dans la collection Details (à savoir celles copiées dans la collection D). Mais qu’arrive-t-il à D ?

Ancien comportement : la collection D est supprimée. L’élément principal ne déclenche aucune notification de modification pour la propriété OrderDetails. ListBox continue d’utiliser la collection D, qui est désormais vide.
Nouveau comportement : la collection D n’est pas modifié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 de manière différente : 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
Portée	Mineur
Version	4.7.2
Type	Reciblage

WPF FocusVisual pour RadioButton et CheckBox s’affichent maintenant correctement lorsque les contrôles n’ont pas de contenu

Détails

Dans .NET Framework 4.7.1 et versions antérieures, WPF System.Windows.Controls.CheckBox et System.Windows.Controls.RadioButton ont des thèmes incohérents et, dans les thèmes Classic et Contraste élevé, des visuels de focus 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 déroutante et l'indicateur 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 classiques et à contraste élevé.

Suggestion

Un développeur ciblant .NET Framework 4.7.2 qui souhaite revenir au comportement dans .NET 4.7.1 devra 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 du framework inférieure à .NET 4.7.2 doit définir les indicateurs AppContext suivants. Notez que tous les indicateurs doivent être définis de manière appropriée et que la version installée du .NET Framework doit être 4.7.2 ou ultérieure. Les applications WPF sont tenues d’opter pour toutes les améliorations d’accessibilité antérieures afin d’obtenir les dernières améliorations. Pour ce faire, vérifiez que les 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
Portée	Microsoft 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 ne pouvaient afficher qu’une sélection de texte 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 versions ultérieures, les développeurs ont la possibilité d’activer un schéma de rendu de sélection non basé sur Ornement qui atténue ce problème.

Suggestion

Un développeur qui souhaite utiliser cette modification doit définir correctement l’indicateur AppContext suivant. Pour utiliser cette fonctionnalité, la version .NET Framework installée doit être 4.7.2 ou ultérieure. Pour activer la sélection non basée sur l’ornement, utilisez l’indicateur AppContext suivant.

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

Nom	Valeur
Portée	Microsoft Edge
Version	4.7.2
Type	Reciblage

Windows Workflow Foundation (WF)

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

Détails

Dans certaines circonstances, lorsque vous utilisez des API IWorkflowInstanceManagement.TransactedCancel ou IWorkflowInstanceManagement.TransactedTerminate pour annuler ou arrêter une instance de service de flux de travail, l’instance de flux de travail peut rencontrer un dépassement de capacité de pile en raison d’une récursivité infinie lorsque 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 flux de travail est dans un état où elle attend l'achèvement d'une autre requête WCF en suspens vers un autre service. Les opérations TransactedCancel et TransactedTerminate créent des éléments de travail mis en file d’attente pour l’instance de service de flux de travail. Ces éléments de travail ne sont pas exécutés dans le cadre du traitement de la demande de TransactedCancel/TransactedTerminate. Étant donné que l’instance de service de flux de travail est occupée à attendre que l’autre requête WCF en attente soit terminée, l’élément de travail créé reste mis en file d'attente. L’opération TransactedCancel/TransactedTerminate se termine et 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 annulation de la transaction ne rejette pas l'élément de travail. Pour résoudre ce problème, à partir de .NET Framework 4.7.2, nous avons introduit un AppSetting qui peut être ajouté au web.config/app.config du service de flux de travail. Cela indique au service d’ignorer les transactions pour TransactedCancel et TransactedTerminate. Cela permet à la transaction de valider sans attendre la persistance de l’instance de flux de travail. L’AppSetting pour cette fonctionnalité est nommé microsoft:WorkflowServices:IgnoreTransactionsForTransactedCancelAndTransactedTerminate. Une valeur de true indique que la transaction doit être ignorée, ce qui évite le dépassement de capacité de la pile. La valeur par défaut de cet AppSetting est false, de sorte que les instances de service de flux de travail existantes ne sont pas affectées.

Suggestion

Si vous utilisez AppFabric ou un autre client IWorkflowInstanceManagement et rencontrez un dépassement de capacité de pile dans l’instance du service de flux de travail lors de la tentative d’annulation ou de fin d’une instance de flux de travail, vous pouvez ajouter ce qui suit à la section <appSettings> du fichier web.config/app.config pour le service de flux de travail :

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

Si vous ne rencontrez pas le problème, vous n’avez pas besoin de le faire.

Nom	Valeur
Portée	Microsoft Edge
Version	4.7.2
Type	Reciblage

Partage via

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

.NET Framework 4.7

ASP.NET

HttpRuntime.AppDomainAppPath lève une exception NullReferenceException

Détails

Suggestion

API affectées

Limiter les requêtes simultanées par session

Détails

Proposition

Réseautage

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

Détails

Suggestion

API affectées

SslStream prend en charge les alertes TLS

Détails

Suggestion

API affectées

Sécurité

CspParameters.ParentWindowHandle attend maintenant la valeur HWND

Détails

Suggestion

API affectées

SslStream prend en charge les alertes TLS

Détails

Suggestion

API affectées

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

Suggestion

API affectées

La sécurité des messages WCF est désormais en mesure d’utiliser TLS1.1 et TLS1.2

Détails

Suggestion

Windows Presentation Foundation (WPF)

Les appels à System.Windows.Input.PenContext.Disable sur les systèmes tactiles peuvent provoquer une ArgumentException.

Détails

Suggestion

NullReferenceException dans le code de gestion des exceptions provenant de ImageSourceConverter.ConvertFrom

Détails

Suggestion

API affectées

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

Détails

Suggestion

Pile tactile basée sur un pointeur WPF

Détails

Suggestion

Windows Workflow Foundation (WF)

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

Détails

Une suggestion

.NET Framework 4.7.1

ASP.NET

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

Détails

Suggestion

Principal

Exceptions de thread d’arrière-plan SerialPort

Détails

Suggestion

API affectées

ServiceBase ne propage pas les exceptions OnStart

Détails

Suggestion

API affectées

Sécurité

Algorithmes SignedXML et SignedXMS par défaut modifiés en SHA256

Détails

Suggestion

API affectées

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

Détails

Suggestion

API affectées

Windows Communication Foundation (WCF)

Amélioration de l’accessibilité pour certains outils du Kit de développement logiciel (SDK) .NET