Partager via

Modifications du runtime pour la migration vers .NET Framework 4.6.x

Cet article répertorie les problèmes de compatibilité des applications qui ont été introduits dans .NET Framework 4.6, 4.6.1 et 4.6.2.

.NET Framework 4.6

ASP.NET

GridViews avec AllowCustomPaging défini sur true peut déclencher l’événement PageIndexChanging lors de la sortie de la page finale de la vue

Détails

Un bogue dans le .NET Framework 4.5 empêche parfois System.Web.UI.WebControls.GridView.PageIndexChanging de se déclencher pour les System.Web.UI.WebControls.GridView dont System.Web.UI.WebControls.GridView.AllowCustomPaging est activé.

Suggestion

Ce problème a été résolu dans .NET Framework 4.6 et peut être résolu en effectuant une mise à niveau vers cette version du .NET Framework. Comme solution de contournement, l’application peut effectuer une opération BindGrid explicite sur n’importe quel Page_Load qui répond à ces conditions (le contrôle System.Web.UI.WebControls.GridView figure dans la dernière page et LastSystem.Web.UI.WebControls.GridView.PageSize est différent de System.Web.UI.WebControls.GridView.PageSize). Vous pouvez également modifier l’application pour autoriser la pagination (au lieu de la pagination personnalisée), car ce scénario n’illustre pas le problème.

Nom Valeur
Étendue Mineur
Version 4.5
Catégorie Temps d'exécution

API affectées

Cœur

Un ConcurrentDictionary sérialisé dans .NET Framework 4.5 avec NetDataContractSerializer ne peut pas être désérialisé par .NET Framework 4.5.1 ou 4.5.2

Détails

En raison des modifications internes apportées au type, ConcurrentDictionary<TKey,TValue> les objets sérialisés avec .NET Framework 4.5 à l’aide du System.Runtime.Serialization.NetDataContractSerializer ne peuvent pas être désérialisés dans .NET Framework 4.5.1 ou dans .NET Framework 4.5.2. Notez que l'opération inverse (sérialisation avec .NET Framework 4.5.x et désérialisation avec .NET Framework 4.5) fonctionne. De même, la sérialisation multiversion 4.x fonctionne avec le .NET Framework 4.6. La sérialisation et la désérialisation avec une seule version du .NET Framework ne sont pas affectées.

Suggestion

S’il est nécessaire de sérialiser et désérialiser un System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue> entre .NET Framework 4.5 et .NET Framework 4.5.1/4.5.2, un sérialiseur différent tel que System.Runtime.Serialization.DataContractSerializer devrait être utilisé au lieu du System.Runtime.Serialization.NetDataContractSerializer. Sinon, étant donné que ce problème est résolu dans .NET Framework 4.6, il peut être résolu en effectuant une mise à niveau vers cette version du .NET Framework.

Nom Valeur
Étendue Mineur
Version 4.5.1
Catégorie Temps d'exécution

API affectées

Non détectable par le biais d’une analyse d’API.

AppDomainSetup.DynamicBase n'est plus randomisé par l'algorithme UseRandomizedStringHashAlgorithm.

Détails

Avant .NET Framework 4.6, la valeur serait aléatoire entre les domaines d’application DynamicBase ou entre les processus, si UseRandomizedStringHashAlgorithm était activée dans le fichier de configuration de l’application. À compter de .NET Framework 4.6, DynamicBase retourne un résultat stable entre différentes instances d’une application en cours d’exécution et entre différents domaines d’application. Les bases dynamiques diffèrent toujours pour différentes applications ; cette modification supprime uniquement l’élément de nommage aléatoire pour différentes instances de la même application.

Suggestion

Soyez conscient que l'activation de UseRandomizedStringHashAlgorithm n'entraînera pas la randomisation de DynamicBase. Si une base aléatoire est nécessaire, elle doit être produite dans le code de votre application plutôt que via cette API.

Nom Valeur
Étendue Microsoft Edge
Version 4,6
Catégorie Temps d'exécution

API affectées

L’appel d’Attribute.GetCustomAttributes sur une propriété d’indexeur ne lève plus AmbiguMatchException si l’ambiguïté peut être résolue par type d’index

Détails

Avant .NET Framework 4.6, l’appel GetCustomAttribute(s) d’une propriété d’indexeur qui diffère d’une autre propriété uniquement par le type de l’index entraînerait un System.Reflection.AmbiguousMatchException. À compter de .NET Framework 4.6, les attributs de la propriété seront correctement retournés.

Suggestion

N’oubliez pas que GetCustomAttribute(s) fonctionnera plus fréquemment maintenant. Si une application s’appuyait précédemment sur le System.Reflection.AmbiguousMatchException, la réflexion doit maintenant être utilisée pour rechercher explicitement plusieurs indexeurs.

Nom Valeur
Étendue Microsoft Edge
Version 4,6
Catégorie Temps d'exécution

API affectées

Les membres COR_PRF_GC_ROOT_HANDLE ne sont pas énumérés par les profileurs

Détails

Dans .NET Framework v4.5.1, l’API RootReferences2() de profilage ne retourne COR_PRF_GC_ROOT_HANDLE jamais de manière incorrecte (elles sont retournées comme COR_PRF_GC_ROOT_OTHER à la place). Ce problème est résolu à partir du .NET Framework 4.6.

Suggestion

Ce problème a été résolu dans .NET Framework 4.6 et peut être résolu en effectuant une mise à niveau vers cette version du .NET Framework.

Nom Valeur
Étendue Mineur
Version 4.5.1
Catégorie Temps d'exécution

API affectées

Non détectable par le biais d’une analyse d’API.

Les eventListeners ETW ne capturent pas d’événements à partir de fournisseurs avec des mots clés explicites (comme le fournisseur TPL)

Détails

Les EventListeners ETW avec un masque de mot clé vide ne capturent pas correctement les événements des fournisseurs avec des mots clés explicites. Dans .NET Framework 4.5, le fournisseur TPL a commencé à fournir des mots clés explicites et a déclenché ce problème. Dans .NET Framework 4.6, Les EventListeners ont été mis à jour pour ne plus avoir ce problème.

Suggestion

Pour contourner ce problème, remplacez les appels à EnableEvents(EventSource, EventLevel) par les appels à la version surchargée de EnableEvents qui spécifie explicitement le masque « tout mot-clé » à utiliser : EnableEvents(eventSource, level, unchecked((EventKeywords)0xFFFFffffFFFFffff)).

Ce problème a également été résolu dans .NET Framework 4.6 et peut être résolu en effectuant une mise à niveau vers cette version du .NET Framework.

Nom Valeur
Étendue Microsoft Edge
Version 4.5
Catégorie Temps d'exécution

API affectées

Le calendrier persan utilise désormais l’algorithme solaire Hijri

Détails

À compter du .NET Framework 4.6, la System.Globalization.PersianCalendar classe utilise l’algorithme solaire Hijri. La conversion de dates entre les System.Globalization.PersianCalendar calendriers et les autres calendriers pourra produire un résultat légèrement différent à partir de la version .NET Framework 4.6 pour les dates antérieures à 1800 ou ultérieures à 2023 (grégorien). En outre, PersianCalendar.MinSupportedDateTime est maintenant March 22, 0622 au lieu de March 21, 0622.

Suggestion

N’oubliez pas que certaines dates anticipées ou tardives peuvent être légèrement différentes lors de l’utilisation de PerseCalendar dans .NET Framework 4.6. En outre, lors de la sérialisation des dates entre les processus qui peuvent s’exécuter sur différentes versions de .NET Framework, ne les stockez pas en tant que chaînes de dates PerseCalendar (car ces valeurs peuvent être différentes).

Nom Valeur
Étendue Mineur
Version 4,6
Catégorie Temps d'exécution

API affectées

Les objets de réflexion ne peuvent plus être passés du code managé aux clients DCOM hors processus

Détails

Les objets de réflexion ne peuvent plus être passés du code managé aux clients DCOM hors processus. Les types suivants sont affectés :

Les appels à IMarshal pour l’objet retournent E_NOINTERFACE.

Suggestion

Mettez à jour le code de marshaling pour qu’il fonctionne avec des objets sans réflexion.

Nom Valeur
Étendue Mineur
Version 4,6
Catégorie Temps d'exécution

API affectées

TargetFrameworkName pour le domaine d’application par défaut n’a plus la valeur Null s’il n’est pas défini

Détails

La System.AppDomainSetup.TargetFrameworkName valeur était précédemment null dans le domaine d’application par défaut, sauf si elle a été définie explicitement. À compter de la version 4.6, la System.AppDomainSetup.TargetFrameworkName propriété du domaine d’application par défaut aura une valeur par défaut dérivée de TargetFrameworkAttribute (le cas échéant). Les domaines d’application non par défaut continuent d’hériter de leur System.AppDomainSetup.TargetFrameworkName domaine d’application par défaut (qui n’aura pas la valeur null dans la version 4.6), sauf s’il est explicitement substitué.

Suggestion

Le code doit être mis à jour pour ne pas dépendre de la TargetFrameworkName valeur null par défaut. S’il est nécessaire que cette propriété continue d’évaluer la valeur Null, elle peut être définie explicitement sur cette valeur.

Nom Valeur
Étendue Microsoft Edge
Version 4,6
Catégorie Temps d'exécution

API affectées

X509Certificate2.ToString(Boolean) ne lève plus d’exception quand .NET ne peut pas gérer le certificat

Détails

Dans .NET Framework 4.5.2 et antérieur, cette méthode levait une exception quand la valeur true était passée au paramètre verbose alors que des certificats non pris en charge par le .NET Framework étaient installés. À présent, la méthode réussit et retourne une chaîne valide qui omet les parties inaccessibles du certificat.

Suggestion

Le code qui dépend de X509Certificate2.ToString(Boolean) doit être mis à jour pour s’attendre à ce que la chaîne retournée omette certaines données du certificat (telles que la clé publique, la clé privée et les extensions), ce qui aurait auparavant entraîné la levée d’une exception par l’API.

Nom Valeur
Étendue Microsoft Edge
Version 4,6
Catégorie Temps d'exécution

API affectées

Données

Une tentative de connexion TCP/IP à une base de données SQL Server qui se résout en localhost échoue

Détails

Dans .NET Framework 4.6 et 4.6.1, la tentative d’une connexion TCP/IP à une base de données SQL Server qui résout à localhost échoue avec l’erreur : « Une erreur liée au réseau ou spécifique à l'instance s’est produite lorsqu’on établit une connexion à SQL Server. ». Le serveur n’a pas été trouvé ou n’a pas été accessible. Vérifiez que le nom de l’instance est correct et que SQL Server est configuré pour autoriser les connexions distantes. (fournisseur : Interfaces réseau SQL, erreur : 26 - Erreur de localisation du serveur/de l’instance spécifié) »

Suggestion

Ce problème a été résolu et le comportement précédent a été restauré dans .NET Framework 4.6.2. Pour vous connecter à une base de données SQL Server qui est résolue par localhost, effectuez une mise à niveau vers .NET Framework 4.6.2.

Nom Valeur
Étendue Mineur
Version 4,6
Catégorie Temps d'exécution

API affectées

Non détectable par le biais d’une analyse d’API.

Débogueur

Les valeurs de fusion Null ne sont pas visibles dans le débogueur jusqu’à une étape ultérieure

Détails

Un bogue dans le .NET Framework 4.5 entraîne les valeurs définies via une opération de fusion de null à ne pas être visibles dans le débogueur immédiatement après l'exécution de l'opération d'affectation lorsqu'elle s'exécute sur la version 64 bits du Framework.

Suggestion

Une nouvelle exécution pas à pas dans le débogueur entraînera la mise à jour correcte de la valeur locale/du champ. De plus, ce problème a été résolu dans .NET Framework 4.6 ; la mise à niveau vers cette version du Framework doit résoudre le problème.

Nom Valeur
Étendue Microsoft Edge
Version 4.5
Catégorie Temps d'exécution

API affectées

Non détectable par le biais d’une analyse d’API.

Réseautage

ContentDisposition DateTimes retourne une chaîne légèrement différente

Détails

Les représentations sous forme de chaîne de System.Net.Mime.ContentDisposition's ont été mises à jour, à compter de la version 4.6, pour toujours représenter le composant horaire d’un System.DateTime avec deux chiffres. Il s’agit de se conformer à RFC822 et RFC2822. ToString() retourne à présent une chaîne légèrement différente dans la version 4.6, lorsque l’un des éléments d’heure de la disposition est antérieur à 10:00. Notez que les ContentDisposition sont parfois sérialisés lors de leur conversion en chaînes. Pour cette raison, les opérations ToString(), les sérialisations et les appels GetHashCode doivent être examinés.

Suggestion

Ne vous attendez pas à ce que les représentations sous forme de chaîne de ContentDispositions provenant de différentes versions du .NET Framework soient correctement comparées les unes aux autres. Reconvertissez les chaînes en ContentDisposition, si possible, avant d’effectuer une comparaison.

Nom Valeur
Étendue Mineur
Version 4,6
Catégorie Temps d'exécution

API affectées

Sérialisation

Le message d’exception a été modifié pour l’échec de la sérialisation de DataContract dans le cas d’un type inconnu

Détails

À compter de .NET Framework 4.6, le message d’exception donné si un System.Runtime.Serialization.DataContractSerializer ou un System.Runtime.Serialization.Json.DataContractJsonSerializer échoue à sérialiser ou désérialiser en raison de « types connus » manquants a été précisé.

Suggestion

Les applications ne doivent pas dépendre de messages d’exception spécifiques. Si une application dépend de ce message, mettez-la à jour pour attendre le nouveau message ou (de préférence) le modifier pour qu'il dépende uniquement du type d’exception.

Nom Valeur
Étendue Microsoft Edge
Version 4,6
Catégorie Temps d'exécution

API affectées

Installation et déploiement

Modifications de version de produit dans .NET Framework 4.6 et versions ultérieures

Détails

Le versionnement logiciel a changé par rapport aux versions antérieures du .NET Framework, et en particulier par rapport au .NET Framework 4, 4.5, 4.5.1 et 4.5.2. Voici les modifications détaillées :

  • La valeur de l’entrée Version dans la clé HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full a changé à 4.6.xxxxx pour .NET Framework 4.6 et ses versions secondaires, et à 4.7.xxxxx pour .NET Framework 4.7 et 4.7.1. Dans .NET Framework 4.5, 4.5.1 et 4.5.2, il a le format 4.5.xxxxx.
  • Le contrôle de version de fichier et de produit pour les fichiers .NET Framework est passé du schéma de contrôle de version antérieur de 4.0.30319.x à 4.6.X.0 pour .NET Framework 4.6 et ses versions de point, et à 4.7.X.0 pour .NET Framework 4.7 et 4.7.1. Vous pouvez voir ces nouvelles valeurs lorsque vous affichez les propriétés du fichier après avoir cliqué avec le bouton droit sur un fichier.
  • Les attributs AssemblyFileVersionAttribute et AssemblyInformationalVersionAttribute des assemblies managés ont des valeurs de version au format 4.6.X.0 pour le .NET Framework 4.6 et ses mises à jour intermédiaires, et 4.7.X.0 pour le .NET Framework 4.7 et 4.7.1.
  • Dans .NET Framework 4.6, 4.6.1, 4.6.2, 4.7 et 4.7.1, la Environment.Version propriété retourne la chaîne 4.0.30319.42000de version fixe. Dans .NET Framework 4, 4.5, 4.5.1 et 4.5.2, il retourne des chaînes de version au format 4.0.30319.xxxxx (par exemple, « 4.0.30319.18010 »). Notez que nous déconseillons au code de l'application de prendre une nouvelle dépendance de la propriété Environment.Version.

Pour plus d’informations, consultez Guide pratique pour déterminer les versions de .NET Framework installées.

Suggestion

En général, les applications doivent dépendre des techniques recommandées pour détecter des éléments tels que la version runtime du .NET Framework et le répertoire d’installation :

Importante

Le nom de la sous-clé n’est NET Framework Setuppas .NET Framework Setup.

  • Pour déterminer le chemin d’accès au répertoire du Common Language Runtime .NET Framework, appelez la RuntimeEnvironment.GetRuntimeDirectory() méthode.
  • Pour obtenir la version clR, appelez la RuntimeEnvironment.GetSystemVersion() méthode. Pour .NET Framework 4 et ses mises à jour mineures (.NET Framework 4.5, 4.5.1, 4.5.2 et .NET Framework 4.6, 4.6.1, 4.6.2, 4.7 et 4.7.1), il retourne la chaîne v4.0.30319.
Nom Valeur
Étendue Mineur
Version 4,6
Catégorie Temps d'exécution

API affectées

Non détectable par le biais d’une analyse d’API.

.NET Framework 4.6 n’utilise pas de version 4.5.x.x lors de l’inscription dans le Registre

Détails

Comme prévu, la clé de version définie dans le Registre (à HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v4\Full) pour .NET Framework 4.6 commence par « 4.6 », et non « 4.5 ». Les applications qui dépendent de ces clés de Registre pour savoir quelles versions du .NET Framework sont installées sur un ordinateur doit être mise à jour pour comprendre que la version 4.6 est une nouvelle version possible et une version compatible avec les versions antérieures de la version 4.5.x.

Suggestion

Mettez à jour les applications vérifiant la présence d'une installation de .NET Framework 4.5 en recherchant les clés de registre de la version 4.5 pour accepter également 4.6.

Nom Valeur
Étendue Microsoft Edge
Version 4,6
Catégorie Temps d'exécution

API affectées

Non détectable par le biais d’une analyse d’API.

Windows Communication Foundation (WCF)

Services WCF qui utilisent NETTCP avec la sécurité SSL et l’authentification par certificat MD5

Détails

.NET Framework 4.6 ajoute TLS 1.1 et TLS 1.2 à la liste des protocoles SSL PAR défaut WCF. Lorsque les ordinateurs clients et serveurs ont installé .NET Framework 4.6 ou version ultérieure, TLS 1.2 est utilisé pour la négociation. TLS 1.2 ne prend pas en charge l’authentification par certificat MD5. Par conséquent, si un client utilise un certificat MD5, le client WCF ne parvient pas à se connecter au service WCF.

Suggestion

Vous pouvez contourner ce problème afin qu’un client WCF puisse se connecter à un serveur WCF en effectuant l’une des opérations suivantes :

  • Mettez à jour le certificat pour ne pas utiliser l’algorithme MD5. Il s’agit de la solution recommandée.
  • Si la liaison n’est pas configurée dynamiquement dans le code source, mettez à jour le fichier de configuration de l’application pour utiliser TLS 1.1 ou une version antérieure du protocole. Cela vous permet de continuer à utiliser un certificat avec l’algorithme de hachage MD5.

Avertissement

Cette solution de contournement n’est pas recommandée, car un certificat avec l’algorithme de hachage MD5 est considéré comme non sécurisé.

Le fichier de configuration suivant effectue cette opération :

<configuration>
  <system.serviceModel>
    <bindings>
      <netTcpBinding>
        <binding>
          <security mode= "None/Transport/Message/TransportWithMessageCredential" >
            <transport clientCredentialType="None/Windows/Certificate"
                       protectionLevel="None/Sign/EncryptAndSign"
                       sslProtocols="Ssl3/Tls1/Tls11">
            </transport>
          </security>
        </binding>
      </netTcpBinding>
    </bindings>
  </system.ServiceModel>
</configuration>

Avertissement

Cette solution de contournement n’est pas recommandée, car un certificat avec l’algorithme de hachage MD5 est considéré comme non sécurisé.

Nom Valeur
Étendue Mineur
Version 4,6
Catégorie Temps d'exécution

API affectées

Non détectable par le biais d’une analyse d’API.

Windows Presentation Foundation (WPF)

Accéder aux éléments sélectionnés d'un DataGrid WPF depuis le gestionnaire de l'événement UnloadingRow de DataGrid peut entraîner une exception NullReferenceException.

Détails

En raison d’un bogue dans .NET Framework 4.5, les gestionnaires d’événements pour les événements DataGrid impliquant la suppression d’une ligne peuvent entraîner la levée d’une System.NullReferenceException s’ils accèdent aux propriétés DataGrid ou System.Windows.Controls.Primitives.Selector.SelectedItem de System.Windows.Controls.Primitives.MultiSelector.SelectedItems.

Suggestion

Ce problème a été résolu dans .NET Framework 4.6 et peut être résolu en effectuant une mise à niveau vers cette version du .NET Framework.

Nom Valeur
Étendue Mineur
Version 4.5
Catégorie Temps d'exécution

API affectées

L’appel d’Items.Refresh dans un contrôle WPF ListBox, ListView ou DataGrid contenant des éléments sélectionnés peut provoquer l’apparition d’éléments en double.

Détails

Dans .NET Framework 4.5, l’appel de ListBox.Items.Refresh à partir du code tandis que les éléments sont sélectionnés dans un System.Windows.Controls.ListBox peut entraîner le doublon des éléments sélectionnés dans la liste. Un problème similaire se produit avec System.Windows.Controls.ListView et System.Windows.Controls.DataGrid. Cette opération est corrigée dans .NET Framework 4.6.

Suggestion

Ce problème peut être traité par programmation en désélectionnant les éléments avant System.Windows.Data.CollectionView.Refresh() d’être appelés, puis en les réélectionnant une fois l’appel terminé. Ce problème a également été résolu dans .NET Framework 4.6 et peut être résolu en effectuant une mise à niveau vers cette version du .NET Framework.

Valeur
Étendue Mineur
Version 4.5
Type Temps d'exécution

API affectées

CoerceIsSelectionBoxHighlighted

Détails

Certaines séquences d’actions impliquant un System.Windows.Controls.ComboBox et sa source de données peut entraîner un System.NullReferenceException.

Suggestion

Si possible, effectuez une mise à niveau vers .NET Framework 4.6.2.

Nom Valeur
Étendue Mineur
Version 4,6
Catégorie Temps d'exécution

API affectées

Problème de liaison ListBoxItem IsSelected avec ObservableCollection<T>.Move

Détails

L'appel de Move(Int32, Int32) ou MoveItem(Int32, Int32) sur une collection liée à un System.Windows.Controls.ListBox avec des éléments sélectionnés peut entraîner un comportement erratique lors de la sélection ou de la désélection future des éléments System.Windows.Controls.ListBox.

Suggestion

Appeler System.Collections.ObjectModel.Collection<T>.Remove(T) et System.Collections.ObjectModel.Collection<T>.Insert(Int32, T) au lieu de Move(Int32, Int32) permettra de contourner ce problème. Ce problème a également été résolu dans .NET Framework 4.6 et peut être résolu en effectuant une mise à niveau vers cette version du .NET Framework.

Nom Valeur
Étendue Mineur
Version 4.5
Catégorie Temps d'exécution

API affectées

Un clic droit sur l’en-tête de ligne d’un DataGrid WPF modifie la sélection de la grille de données

Détails

Cliquer avec le bouton droit sur un en-tête de ligne sélectionné System.Windows.Controls.DataGrid lorsque plusieurs lignes sont sélectionnées entraîne une modification de la sélection de System.Windows.Controls.DataGrid, qui se limite alors à cette ligne uniquement.

Suggestion

Ce problème a été résolu dans .NET Framework 4.6 et peut être résolu en effectuant une mise à niveau vers cette version du .NET Framework.

Nom Valeur
Étendue Microsoft Edge
Version 4.5
Catégorie Temps d'exécution

API affectées

WPF génère un processus wisptis.exe qui peut figer la souris

Détails

Un problème a été introduit dans 4.5.2, qui génère un exécutable wisptis.exe qui peut figer les entrées de la souris.

Suggestion

Un correctif pour ce problème est disponible dans une version de maintenance du .NET Framework 4.5.2 (correctif cumulatif 3026376) ou en effectuant une mise à niveau vers .NET Framework 4.6

Nom Valeur
Étendue Majeur
Version 4.5.2
Catégorie Temps d'exécution

API affectées

Non détectable par le biais d’une analyse d’API.

La vérification orthographique WPF dans les contrôles compatibles texte ne fonctionne pas dans Windows 10 pour les langues qui ne se trouvent pas dans la liste des langues d’entrée du système d’exploitation.

Détails

Lors de l’exécution sur Windows 10, le vérificateur orthographique peut ne pas fonctionner pour les contrôles compatibles avec le texte WPF, car les fonctionnalités de vérification orthographique de plateforme sont disponibles uniquement pour les langues présentes dans la liste des langues d’entrée. Dans Windows 10, lorsqu’une langue est ajoutée à la liste des claviers disponibles, Windows télécharge et installe automatiquement un package de fonctionnalité à la demande correspondant qui fournit des fonctionnalités de vérification orthographique. En ajoutant la langue à la liste des langues d’entrée, le vérificateur orthographique sera pris en charge.

Suggestion

N’oubliez pas que la langue ou le texte à vérifier orthographique doit être ajouté comme langue d’entrée pour que la vérification orthographique fonctionne dans Windows 10.

Nom Valeur
Étendue Microsoft Edge
Version 4,6
Catégorie Temps d'exécution

API affectées

Non détectable par le biais d’une analyse d’API.

Les fenêtres WPF sont rendues sans découpage lors de l’extension en dehors d’un seul moniteur

Détails

Dans .NET Framework 4.6 s’exécutant sur Windows 8 et versions ultérieures, la fenêtre entière est rendue sans découpage lorsqu’elle s’étend en dehors d’un affichage unique dans un scénario multi-moniteur. Ceci diffère des versions précédentes du .NET Framework, qui découpait les fenêtres WPF étendues au-delà d’un même écran.

Suggestion

Ce comportement (découper ou non) peut être défini explicitement avec l’élément <EnableMultiMonitorDisplayClipping> de <appSettings> dans le fichier de configuration d’une application, ou en définissant la propriété EnableMultiMonitorDisplayClipping au démarrage de l’application.

Nom Valeur
Étendue Mineur
Version 4,6
Catégorie Temps d'exécution

API affectées

Non détectable par le biais d’une analyse d’API.

.NET Framework 4.6.1

Outils

Contract.Invariant ou Contract.Requires<TException> ne considère pas String.IsNullOrEmpty comme pur

Détails

Pour les applications qui ciblent .NET Framework 4.6.1, si le contrat invariant pour Contract.Invariant ou le contrat de condition préalable pour Requires appelle la méthode String.IsNullOrEmpty, le réécriteur émet l’avertissement du compilateur CC1036 : « Appel détecté à la méthode « System.String.IsNullOrWhiteSpace(System.String) » sans [Pure] dans la méthode. Il s’agit d’un avertissement du compilateur plutôt que d’une erreur du compilateur.

Suggestion

Ce comportement a été résolu dans le problème GitHub #339. Pour éliminer cet avertissement, vous pouvez télécharger et compiler une version mise à jour du code source pour l’outil Contrats de code à partir de GitHub. Les informations de téléchargement se trouvent en bas de la page.

Nom Valeur
Étendue Mineur
Version 4.6.1
Catégorie Temps d'exécution

API affectées

Windows Presentation Foundation (WPF)

Défilement des éléments d’une liste plate avec des éléments de différentes hauteurs en pixels

Détails

Lorsqu’un System.Windows.Controls.ItemsControl affiche une collection à l’aide de la virtualisation (IsVirtualizing=true) et du défilement d’éléments (ScrollUnit=Item), et lorsque le contrôle défile pour afficher un élément dont la hauteur en pixels diffère de celle de ses voisins, le System.Windows.Controls.VirtualizingStackPanel itère sur tous les éléments de la collection. L’interface utilisateur ne répond pas pendant cette itération. L’itération se produit dans d’autres circonstances, même dans les versions précédentes du .NET Framework. Par exemple, cela se produit lors du défilement de pixels (ScrollUnit=Pixel) en rencontrant un élément d'une hauteur de pixel différente, ainsi que lors du défilement des données hiérarchiques d'élément (comme un System.Windows.Controls.TreeView ou un System.Windows.Controls.ItemsControl avec l’activation de regroupement) en rencontrant un élément ayant un nombre d’éléments descendants différent de ses voisins. Dans le cas du défilement d'éléments avec une hauteur de pixel différente, l’itération a été introduite dans .NET Framework 4.6.1 pour corriger les bogues dans la disposition des données hiérarchiques. Il n’est pas nécessaire si les données sont plates (aucune hiérarchie) et .NET Framework 4.6.2 ne le fait pas dans ce cas.

Suggestion

Si l’itération se produit dans .NET Framework 4.6.1, mais pas dans les versions antérieures, autrement dit, si l’élément System.Windows.Controls.ItemsControl fait défiler une liste plate avec des éléments de hauteur de pixels différentes , il existe deux remèdes :

  • Installez .NET Framework 4.6.2.
  • Installez le correctif logiciel HR 1605 pour .NET Framework 4.6.1.
Nom Valeur
Étendue Mineur
Version 4.6.1
Catégorie Temps d'exécution

API affectées

ObjectDisposedException levée par le vérificateur orthographique de WPF

Détails

Les applications WPF plantent parfois lors de l’arrêt de l’application avec une System.ObjectDisposedException levée par le vérificateur orthographique. Cette opération est corrigée dans .NET Framework 4.7 WPF en gérant correctement l’exception et en garantissant ainsi que les applications ne sont plus affectées de manière négative. Il convient de noter que des exceptions occasionnelles de première chance continuent d’être observées dans les applications s’exécutant sous un débogueur.

Suggestion

Mise à niveau vers .NET Framework 4.7

Nom Valeur
Étendue Microsoft Edge
Version 4.6.1
Catégorie Temps d'exécution

API affectées

Non détectable par le biais d’une analyse d’API.

La vérification orthographique WPF échoue de manière inattendue

Détails

Cela inclut un certain nombre de problèmes de vérificateur d’orthographe WPF :

  • Le vérificateur orthographique de WPF lève parfois System.Runtime.InteropServices.COMException
  • Le vérificateur orthographique WPF échoue avec UnauthorizedAccessException lorsque les applications sont lancées à l'aide de « Exécuter en tant qu'utilisateur différent »
  • WpF Spell Checker identifie incorrectement les erreurs d’orthographe dans des mots composés comme « Hausnummer » en allemand.

Suggestion

Problème n°1 - Ce problème a été résolu dans .NET Framework 4.6.2 Problème #2 - Le vérificateur orthographique WPF n’est plus pris en charge lorsque les applications sont lancées à l’aide de « exécuter en tant qu’utilisateur différent ». À compter de .NET Framework 4.6.2, les applications lancées de cette façon ne se bloqueront plus de manière inattendue. Au lieu de cela, le vérificateur orthographique sera désactivé en mode silencieux. Problème n° 3 : cette opération a été corrigée dans .NET Framework 4.6.2.

Nom Valeur
Étendue Microsoft Edge
Version 4.6.1
Catégorie Temps d'exécution

API affectées

Non détectable par le biais d’une analyse d’API.

.NET Framework 4.6.2

Données

Une tentative de connexion TCP/IP à une base de données SQL Server qui se résout en localhost échoue

Détails

Dans .NET Framework 4.6 et 4.6.1, la tentative d’une connexion TCP/IP à une base de données SQL Server qui résout à localhost échoue avec l’erreur : « Une erreur liée au réseau ou spécifique à l'instance s’est produite lorsqu’on établit une connexion à SQL Server. ». Le serveur n’a pas été trouvé ou n’a pas été accessible. Vérifiez que le nom de l’instance est correct et que SQL Server est configuré pour autoriser les connexions distantes. (fournisseur : Interfaces réseau SQL, erreur : 26 - Erreur de localisation du serveur/de l’instance spécifié) »

Suggestion

Ce problème a été résolu et le comportement précédent a été restauré dans .NET Framework 4.6.2. Pour vous connecter à une base de données SQL Server qui est résolue par localhost, effectuez une mise à niveau vers .NET Framework 4.6.2.

Nom Valeur
Étendue Mineur
Version 4,6
Catégorie Temps d'exécution

API affectées

Non détectable par le biais d’une analyse d’API.

La période de blocage du pool de connexions pour les bases de données Azure SQL est supprimée

Détails

À compter de .NET Framework 4.6.2, pour les demandes d’ouverture de connexion aux bases de données Azure SQL connues (*.database.windows.net, *.database.chinacloudapi.cn, *.database.usgovcloudapi.net, *.database.cloudapi.de), la période de blocage du pool de connexions est supprimée et les erreurs d’ouverture de connexion ne sont pas mises en cache. Les tentatives de nouvelle tentative de demandes d’ouverture de connexion se produisent presque immédiatement après les erreurs de connexion temporaires. Cette modification permet que la tentative de connexion soit réessayée immédiatement pour les bases de données SQL Azure, ce qui améliore les performances des applications alimentées par le cloud. Pour toutes les autres tentatives de connexion, la période de blocage du pool de connexions continue d’être appliquée.

Dans .NET Framework 4.6.1 et versions antérieures, lorsqu’une application rencontre un échec de connexion temporaire lors de la connexion à une base de données, la tentative de connexion ne peut pas être retentée rapidement, car le pool de connexions met en cache l’erreur et la réexécrit pendant 5 secondes à 1 minute. Pour plus d’informations, consultez Regroupement de connexions SQL Server (ADO.NET). Ce comportement est problématique pour les connexions aux bases de données Azure SQL, qui échouent souvent avec des erreurs temporaires qui sont généralement récupérées à partir de quelques secondes. La fonctionnalité de blocage du pool de connexions signifie que l’application ne peut pas se connecter à la base de données pendant une longue période, même si la base de données est disponible et que l’application doit s’afficher en quelques secondes.

Suggestion

Si ce comportement n’est pas souhaitable, vous pouvez configurer la période de blocage du pool de connexions en définissant la System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod propriété introduite dans .NET Framework 4.6.2. La valeur de la propriété est membre de l’énumération System.Data.SqlClient.PoolBlockingPeriod qui peut prendre l’une des trois valeurs suivantes :

Vous pouvez restaurer le comportement précédent en définissant la System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod propriété sur AlwaysBlock.

Nom Valeur
Étendue Mineur
Version 4.6.2
Catégorie Temps d'exécution

API affectées

Mondialisation

Catégories Unicode standard 8.0 désormais prises en charge

Détails

Dans .NET Framework 4.6.2, les données Unicode ont été mises à niveau de la version 6.3 standard Unicode vers la version 8.0. Lors de la demande de catégories de caractères Unicode dans .NET Framework 4.6.2, certains résultats peuvent ne pas correspondre aux résultats des versions précédentes du .NET Framework. Ce changement affecte principalement les syllabes Cherokee et voyelles diacritiques nouveau taï-lue ainsi que les accents toniques.

Suggestion

Passez en revue le code et supprimez/modifiez la logique qui dépend des catégories de caractères Unicode codées en dur.

Nom Valeur
Étendue Mineur
Version 4.6.2
Catégorie Temps d'exécution

API affectées

Sécurité

RSACng et DSACng sont à nouveau utilisables dans les scénarios de confiance partielle

Détails

CngLightup (utilisé dans plusieurs API de chiffrement de niveau supérieur, par exemple System.Security.Cryptography.Xml.EncryptedXml) et System.Security.Cryptography.RSACng , dans certains cas, reposent sur une confiance totale. Ces éléments comprennent P/Invokes sans l’assertion d’autorisations SecurityPermissionFlag.UnmanagedCode et des chemins de code où System.Security.Cryptography.CngKey a des demandes d’autorisation pour SecurityPermissionFlag.UnmanagedCode. À compter du .NET Framework 4.6.2, CngLightup a été utilisé pour basculer vers System.Security.Cryptography.RSACng dans la mesure du possible. Par conséquent, les applications de confiance partielle qui utilisaient correctement System.Security.Cryptography.Xml.EncryptedXml ont commencé à échouer et à lever des exceptions SecurityException. Cette modification ajoute les assertions nécessaires afin que toutes les fonctions utilisant CngLightup disposent des autorisations requises.

Suggestion

Si cette modification dans .NET Framework 4.6.2 a affecté négativement vos applications d’approbation partielle, effectuez une mise à niveau vers .NET Framework 4.7.1.

Nom Valeur
Étendue Microsoft Edge
Version 4.6.2
Catégorie Temps d'exécution

API affectées

RSACng.VerifyHash retourne désormais False pour tout échec de vérification

Détails

À compter du .NET Framework 4.6.2, cette méthode retourne False si la signature elle-même est mal mise en forme. Elle retourne désormais false pour toute défaillance de vérification. Dans .NET Framework 4.6 et 4.6.1, la méthode lève une exception System.Security.Cryptography.CryptographicException si la signature elle-même est mal mise en forme.

Suggestion

Tout code dont l'exécution dépend de la manipulation de System.Security.Cryptography.CryptographicException doit plutôt s'exécuter si la validation échoue et que la méthode renvoie False.

Nom Valeur
Étendue Mineur
Version 4.6.2
Catégorie Temps d'exécution

API affectées

Modifications avec rupture pour SignedXml et EncryptedXml

Détails

Dans .NET Framework 4.6.2, les correctifs de sécurité dans System.Security.Cryptography.Xml.SignedXml et System.Security.Cryptography.Xml.EncryptedXml mènent à différents comportements d’exécution. Par exemple:

  • Si un document a plusieurs éléments avec le même id attribut et qu’une signature cible l’un de ces éléments comme la racine de la signature, le document est désormais considéré comme non valide.
  • Les documents utilisant des algorithmes de transformation XPath non canoniques dans les références sont désormais considérés comme non valides.
  • Les documents utilisant des algorithmes de transformation XSLT non canoniques dans les références sont désormais considérés comme non valides.
  • Tout programme qui utilise des signatures détachées de ressources externes ne pourra pas le faire.

Suggestion

Les développeurs pourraient vouloir examiner l'utilisation de XmlDsigXsltTransform et XmlDsigXsltTransform, ainsi que les types dérivés de Transform, car un récepteur de documents pourrait ne pas être en mesure de les traiter.

Nom Valeur
Étendue Mineur
Version 4.6.2
Catégorie Temps d'exécution

API affectées

Windows Communication Foundation (WCF)

Supprimer Ssl3 de WCF TransportDefaults

Détails

Lorsque vous utilisez NetTcp avec sécurité de transport et un type de certificat d’informations d’identification, le protocole SSL 3 n’est plus un protocole par défaut utilisé pour négocier une connexion sécurisée. Dans la plupart des cas, il ne doit pas y avoir d’impact sur les applications existantes, car TLS 1.0 a toujours été inclus dans la liste des protocoles pour NetTcp. Tous les clients existants doivent pouvoir négocier une connexion à l’aide d’au moins TLS1.0.

Suggestion

Si Ssl3 est requis, utilisez l’un des mécanismes de configuration suivants pour ajouter Ssl3 à la liste des protocoles négociés.

Nom Valeur
Étendue Microsoft Edge
Version 4.6.2
Catégorie Temps d'exécution

API affectées

Windows Presentation Foundation (WPF)

La modification de la propriété IsEnabled du parent d’un contrôle TextBlock affecte tous les contrôles enfants

Détails

À compter du .NET Framework 4.6.2, la modification de la System.Windows.UIElement.IsEnabled propriété du parent d’un System.Windows.Controls.TextBlock contrôle affecte tous les contrôles enfants (tels que les liens hypertexte et les boutons) du System.Windows.Controls.TextBlock contrôle. Dans .NET Framework 4.6.1 et les versions antérieures, les contrôles à l’intérieur d’un objet System.Windows.Controls.TextBlock ne reflètent pas toujours l’état de la System.Windows.UIElement.IsEnabled propriété du System.Windows.Controls.TextBlock parent.

Suggestion

Aucun. Cette modification est conforme au comportement attendu pour les contrôles à l’intérieur d’un System.Windows.Controls.TextBlock contrôle.

Nom Valeur
Étendue Mineur
Version 4.6.2
Catégorie Temps d'exécution

API affectées

CoerceIsSelectionBoxHighlighted

Détails

Certaines séquences d’actions impliquant un System.Windows.Controls.ComboBox et sa source de données peut entraîner un System.NullReferenceException.

Suggestion

Si possible, effectuez une mise à niveau vers .NET Framework 4.6.2.

Nom Valeur
Étendue Mineur
Version 4,6
Catégorie Temps d'exécution

API affectées

DataGridCellsPanel.BringIndexIntoView génère une ArgumentOutOfRangeException

Détails

ScrollIntoView(Object) fonctionne de manière asynchrone lorsque la virtualisation des colonnes est activée, mais que les largeurs de colonne n’ont pas encore été déterminées. Si des colonnes sont supprimées avant que le travail asynchrone ne se produise, un System.ArgumentOutOfRangeException peut se produire.

Suggestion

L’une des opérations suivantes :

  • Effectuez une mise à niveau vers .NET Framework 4.7.
  • Installez le dernier correctif de maintenance pour .NET Framework 4.6.2.
  • Évitez de supprimer des colonnes tant que la réponse asynchrone à ScrollIntoView(Object) n’est pas terminée.
Nom Valeur
Étendue Microsoft Edge
Version 4.6.2
Catégorie Temps d'exécution

API affectées

Défilement horizontal et virtualisation

Détails

Cette modification s’applique à une System.Windows.Controls.ItemsControl qui effectue sa propre virtualisation dans la direction orthogonale à la direction de défilement principale (l’exemple principal est System.Windows.Controls.DataGrid avec EnableColumnVirtualization="True"). Le résultat de certaines opérations de défilement horizontal a été modifié pour produire des résultats plus intuitifs et plus analogues aux résultats d’opérations verticales comparables.

Les opérations incluent « Scroll Here » et « Right Edge », pour utiliser les noms du menu obtenu en cliquant avec le bouton droit sur une barre de défilement horizontale. Toutes deux calculent un décalage candidat et appellent SetHorizontalOffset(Double).

Après avoir défilé jusqu’au nouveau décalage, la notion de « ici » ou « bord droit » peut avoir changé, car le contenu récemment dévirtualisé a modifié la valeur de System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth.

Avant .NET Framework 4.6.2, l’opération de défilement utilise simplement le décalage candidat, même s’il n’est peut-être pas « ici » ou sur le « bord droit ». Cela entraîne des effets tels que le « rebondissement » du curseur de défilement, comme illustré dans l’exemple. Supposons qu’un System.Windows.Controls.DataGrid ait ExtentWidth=1000 et Width=200. Un défilement vers « Bord droit » utilise un décalage candidat de 1000-200 = 800. Lors du défilement jusqu’à ce décalage, les nouvelles colonnes sont dévirtualisées. Supposons qu’elles sont très larges, de sorte que System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth passe à 2000. Le défilement se termine par HorizontalOffset=800, et le pouce « rebondit » vers le milieu de la barre de défilement - précisément à 800/2000 = 40%.

Le changement consiste à recalculer un nouveau décalage candidat quand cette situation se produit, puis à réessayer. (C'est ainsi que le défilement vertical fonctionne déjà.)

La modification produit une expérience plus prévisible et intuitive pour l’utilisateur final, mais elle peut également affecter toute application qui dépend de la valeur exacte d’après System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset un défilement horizontal, qu’elle soit appelée par l’utilisateur final ou par un appel explicite à SetHorizontalOffset(Double).

Suggestion

Une application qui utilise une valeur prédite pour System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset doit être modifiée pour extraire la valeur réelle (et la valeur de System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth) après tout défilement horizontal susceptible de changer System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth en raison de la dévirtualisation.

Nom Valeur
Étendue Mineur
Version 4.6.2
Catégorie Temps d'exécution

API affectées

Items.Clear ne supprime pas les doublons de SelectedItems

Détails

Supposons qu’un sélecteur (avec une sélection multiple activée) ait des doublons dans sa System.Windows.Controls.Primitives.MultiSelector.SelectedItems collection . Le même élément apparaît plusieurs fois. La suppression de ces éléments de la source de données (par exemple, en appelant Items.Clear) échoue à les retirer de System.Windows.Controls.Primitives.MultiSelector.SelectedItems, et seule la première instance est supprimée. En outre, l’utilisation ultérieure de System.Windows.Controls.Primitives.MultiSelector.SelectedItems (par exemple SelectedItems.Clear()) peut rencontrer des problèmes tels que System.ArgumentException, car System.Windows.Controls.Primitives.MultiSelector.SelectedItems contient des éléments qui ne se trouvent plus dans la source de données.

Suggestion

Mettez à niveau si possible vers .NET Framework 4.6.2.

Nom Valeur
Étendue Mineur
Version 4.5
Catégorie Temps d'exécution

API affectées

Défilement des éléments d’une liste plate avec des éléments de différentes hauteurs en pixels

Détails

Lorsqu’un System.Windows.Controls.ItemsControl affiche une collection à l’aide de la virtualisation (IsVirtualizing=true) et du défilement d’éléments (ScrollUnit=Item), et lorsque le contrôle défile pour afficher un élément dont la hauteur en pixels diffère de celle de ses voisins, le System.Windows.Controls.VirtualizingStackPanel itère sur tous les éléments de la collection. L’interface utilisateur ne répond pas pendant cette itération. L’itération se produit dans d’autres circonstances, même dans les versions précédentes du .NET Framework. Par exemple, cela se produit lors du défilement de pixels (ScrollUnit=Pixel) en rencontrant un élément d'une hauteur de pixel différente, ainsi que lors du défilement des données hiérarchiques d'élément (comme un System.Windows.Controls.TreeView ou un System.Windows.Controls.ItemsControl avec l’activation de regroupement) en rencontrant un élément ayant un nombre d’éléments descendants différent de ses voisins. Dans le cas du défilement d'éléments avec une hauteur de pixel différente, l’itération a été introduite dans .NET Framework 4.6.1 pour corriger les bogues dans la disposition des données hiérarchiques. Il n’est pas nécessaire si les données sont plates (aucune hiérarchie) et .NET Framework 4.6.2 ne le fait pas dans ce cas.

Suggestion

Si l’itération se produit dans .NET Framework 4.6.1, mais pas dans les versions antérieures, autrement dit, si l’élément System.Windows.Controls.ItemsControl fait défiler une liste plate avec des éléments de hauteur de pixels différentes , il existe deux remèdes :

  • Installez .NET Framework 4.6.2.
  • Installez le correctif logiciel HR 1605 pour .NET Framework 4.6.1.
Nom Valeur
Étendue Mineur
Version 4.6.1
Catégorie Temps d'exécution

API affectées

L’arrière-plan RibbonGroup est défini sur transparent dans les builds localisées

Détails

System.Windows.Controls.Ribbon.RibbonGroup l’arrière-plan des builds localisées a constamment été peint avec un pinceau transparent, ce qui entraîne une mauvaise expérience utilisateur. Cela est résolu dans le correctif WPF .NET Framework 4.7 en mettant à jour les ressources localisées pour System.Windows.Controls.Ribbon.RibbonGroup, ce qui garantit à son tour que le pinceau approprié est sélectionné.

Suggestion

Mise à niveau vers .NET Framework 4.7

Nom Valeur
Étendue Microsoft Edge
Version 4.6.2
Catégorie Temps d'exécution

API affectées

Non détectable par le biais d’une analyse d’API.

La vérification orthographique WPF échoue de manière inattendue

Détails

Cela inclut un certain nombre de problèmes de vérificateur d’orthographe WPF :

  • Le vérificateur orthographique de WPF lève parfois System.Runtime.InteropServices.COMException
  • Le vérificateur orthographique WPF échoue avec UnauthorizedAccessException lorsque les applications sont lancées à l'aide de « Exécuter en tant qu'utilisateur différent »
  • WpF Spell Checker identifie incorrectement les erreurs d’orthographe dans des mots composés comme « Hausnummer » en allemand.

Suggestion

Problème n°1 - Ce problème a été résolu dans .NET Framework 4.6.2 Problème #2 - Le vérificateur orthographique WPF n’est plus pris en charge lorsque les applications sont lancées à l’aide de « exécuter en tant qu’utilisateur différent ». À compter de .NET Framework 4.6.2, les applications lancées de cette façon ne se bloqueront plus de manière inattendue. Au lieu de cela, le vérificateur orthographique sera désactivé en mode silencieux. Problème n° 3 : cette opération a été corrigée dans .NET Framework 4.6.2.

Nom Valeur
Étendue Microsoft Edge
Version 4.6.1
Catégorie Temps d'exécution

API affectées

Non détectable par le biais d’une analyse d’API.

  • Last updated on