Partager via

Changements de runtime pour la migration vers .NET Framework 4.6.x

  • Article

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

.NET Framework 4.6

ASP.NET

Les contrôles GridView avec la valeur true définie pour AllowCustomPaging peuvent déclencher l’événement PageIndexChanging en quittant la dernière page de la vue

Détails

Un bogue dans .NET Framework 4.5 contraint parfois System.Web.UI.WebControls.GridView.PageIndexChanging à ne pas se déclencher pour les System.Web.UI.WebControls.GridView qui ont activé System.Web.UI.WebControls.GridView.AllowCustomPaging.

Suggestion

Ce problème a été corrigé dans .NET Framework 4.6 et vous pouvez le résoudre en effectuant la 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). L’application peut également être modifiée pour autoriser la pagination (au lieu de la pagination personnalisée), comme ce scénario ne présente pas le problème.

Nom Valeur
Étendue Secondaire
Version 4,5
Type Runtime

API affectées

Core

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

Détails

En raison des modifications internes apportées au type, les objets ConcurrentDictionary<TKey,TValue> qui sont sérialisés avec .NET Framework 4.5 à l’aide de System.Runtime.Serialization.NetDataContractSerializer ne peuvent pas être désérialisés dans .NET Framework 4.5.1 ni .NET Framework 4.5.2. Notez toutefois que l’inverse fonctionne (c’est-à-dire sérialiser avec .NET Framework 4.5.x et désérialiser avec .NET Framework 4.5). De même, toutes les sérialisations interversions 4.x fonctionnent avec .NET Framework 4.6. La sérialisation et la désérialisation à l’aide d’une même version du .NET Framework ne sont pas affectées.

Suggestion

S’il est nécessaire de sérialiser et de désérialiser System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue> entre .NET Framework 4.5 et .NET Framework 4.5.1/4.5.2, un sérialiseur comme System.Runtime.Serialization.DataContractSerializer doit être utilisé au lieu de System.Runtime.Serialization.NetDataContractSerializer. Étant donné que ce problème a été résolu dans le .NET Framework 4.6, vous pouvez également mettre à niveau votre version du .NET Framework.

Nom Valeur
Étendue Secondaire
Version 4.5.1
Type Runtime

API affectées

Non détectable via l’analyse des API.

AppDomainSetup.DynamicBase n’est plus aléatoire en activant UseRandomizedStringHashAlgorithm

Détails

Avant .NET Framework 4.6, la valeur de DynamicBase était aléatoire entre les domaines d’application, ou entre les processus, si UseRandomizedStringHashAlgorithm était activé 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 seront toujours différentes 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

Gardez à l’esprit que l’activation de UseRandomizedStringHashAlgorithm ne rendra pas DynamicBase aléatoire. Si une base aléatoire est nécessaire, elle doit être générée dans le code de votre application plutôt que via cette API.

Nom Valeur
Étendue Edge
Version 4.6
Type Runtime

API affectées

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

Détails

Avant le .NET Framework 4.6, l’appel de GetCustomAttribute(s) sur une propriété d’indexeur qui différait d’une autre propriété uniquement par son type d’index entraînait une System.Reflection.AmbiguousMatchException. À compter de la version 4.6 du .NET Framework, les attributs de la propriété sont correctement retournés.

Suggestion

Notez que GetCustomAttribute(s) fonctionne plus fréquemment à présent. Si une application comptait sur l’exception System.Reflection.AmbiguousMatchException, utilisez la réflexion pour rechercher explicitement plusieurs indexeurs.

Nom Valeur
Étendue Edge
Version 4.6
Type Runtime

API affectées

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

Détails

Dans .NET Framework 4.5.1, l’API de profilage RootReferences2() ne retourne jamais correctement COR_PRF_GC_ROOT_HANDLE (ils sont retournés comme COR_PRF_GC_ROOT_OTHER à la place). Ce problème est résolu depuis .NET Framework 4.6.

Suggestion

Ce problème a été corrigé dans .NET Framework 4.6 et vous pouvez le résoudre en effectuant la mise à niveau vers cette version du .NET Framework.

Nom Valeur
Étendue Secondaire
Version 4.5.1
Type Runtime

API affectées

Non détectable via l’analyse des API.

Les EventListeners ETW ne capturent pas les événements provenant 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 provenant de fournisseurs ayant des mots clés explicites. Dans le .NET Framework 4.5, le fournisseur TPL fournissait des mots clés explicites et provoquait ce problème. Dans le .NET Framework 4.6, les EventListeners ont été mis à jour pour ne plus causer ce problème.

Suggestion

Pour contourner ce problème, remplacez les appels à EnableEvents(EventSource, EventLevel) par les appels à la surcharge EnableEvents qui spécifie explicitement le masque « any keywords » à utiliser : EnableEvents(eventSource, level, unchecked((EventKeywords)0xFFFFffffFFFFffff)).

Étant donné que ce problème a été résolu dans le .NET Framework 4.6, vous pouvez également mettre à niveau votre version du .NET Framework.

Nom Valeur
Étendue Edge
Version 4,5
Type Runtime

API affectées

Le calendrier persan utilise désormais l’algorithme solaire hégirien

Détails

À compter de .NET Framework 4.6, la classe System.Globalization.PersianCalendar utilise l’algorithme solaire hégirien. La conversion de dates entre le calendrier System.Globalization.PersianCalendar et les autres calendriers peut produire un résultat légèrement différent à compter de .NET Framework 4.6 pour les dates antérieures à 1800 ou postérieures à 2023 (calendrier grégorien). De plus, PersianCalendar.MinSupportedDateTime est désormais March 22, 0622 au lieu de March 21, 0622.

Suggestion

Notez que certaines dates anciennes ou futures peuvent être légèrement différentes quand vous utilisez le calendrier persan dans .NET Framework 4.6. En outre, quand vous sérialisez des dates dans plusieurs processus qui peuvent s’exécuter sur des versions différentes du .NET Framework, ne les stockez pas sous forme de chaînes de date PersianCalendar (puisque ces valeurs peuvent être différentes).

Nom Valeur
Étendue Secondaire
Version 4.6
Type Runtime

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 concerné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 Secondaire
Version 4.6
Type Runtime

API affectées

Dans le domaine d’application par défaut, TargetFrameworkName ne prend plus la valeur Null par défaut quand il n’est pas défini

Détails

Avant, System.AppDomainSetup.TargetFrameworkName était défini sur la valeur Null dans le domaine d’application par défaut quand il n’était pas défini explicitement. À compter de la version 4.6, la valeur par défaut de la propriété System.AppDomainSetup.TargetFrameworkName du domaine d’application par défaut est dérivée de TargetFrameworkAttribute (si celui-ci est présent). Les domaines d’application autres que ceux par défaut continuent d’hériter leur valeur System.AppDomainSetup.TargetFrameworkName du domaine d’application par défaut (qui n’aura pas la valeur Null par défaut dans la version 4.6), sauf si cette valeur est substituée explicitement.

Suggestion

Le code doit être mis à jour pour ne pas attendre que TargetFrameworkName ait la valeur Null par défaut. Si vous avez besoin que cette propriété continue de prendre la valeur Null, vous pouvez la définir explicitement sur cette valeur.

Nom Valeur
Étendue Edge
Version 4.6
Type Runtime

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 n’échoue plus 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 Edge
Version 4.6
Type Runtime

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, une tentative de connexion TCP/IP à une base de données SQL Server qui se résout en localhost échoue avec l’erreur « Une erreur liée au réseau ou spécifique à l’instance s’est produite lors de l’établissement d’une connexion au Serveur SQL. Le serveur est introuvable ou inaccessible. Vérifiez que le nom de l’instance est correct et que SQL Server est configuré pour autoriser les connexions à distance. (Fournisseur : interface réseau SQL, Erreur : 26 - Erreur lors de la localisation du serveur/de l’instance spécifiés) »

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 se résout en localhost, effectuez une mise à niveau vers .NET Framework 4.6.2.

Nom Valeur
Étendue Secondaire
Version 4.6
Type Runtime

API affectées

Non détectable via l’analyse des 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.NET Framework 4.5 empêche de voir les valeurs définies via une opération de fusion Null dans le débogueur immédiatement après le déroulement de l’opération d’assignation lors de l’exécution de la version 64 bits du .NET Framework.

Suggestion

Une nouvelle exécution pas à pas dans le débogueur entraînera la mise à jour correcte de la valeur locale/du champ. Par ailleurs, ce problème a été corrigé dans .NET Framework 4.6 et vous pouvez le résoudre en effectuant la mise à niveau vers cette version du .NET Framework.

Nom Valeur
Étendue Edge
Version 4,5
Type Runtime

API affectées

Non détectable via l’analyse des API.

Mise en réseau

Les DateTime ContentDisposition retournent une chaîne légèrement différente

Détails

À compter de la version 4.6, les représentations sous forme de chaîne des System.Net.Mime.ContentDisposition ont été mises à jour pour toujours représenter le composant d’heure d’une valeur System.DateTime avec deux chiffres. Ce changement a pour but de se conformer aux normes 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 des ContentDisposition issues de différentes versions du .NET Framework puissent être comparées correctement. Reconvertissez les chaînes en ContentDisposition, si possible, avant d’effectuer une comparaison.

Nom Valeur
Étendue Secondaire
Version 4.6
Type Runtime

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 affiché si un System.Runtime.Serialization.DataContractSerializer ou System.Runtime.Serialization.Json.DataContractJsonSerializer ne parvient pas à sérialiser ni à désérialiser en l’absence de « types connus » a été clarifié.

Suggestion

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

Nom Valeur
Étendue Edge
Version 4.6
Type Runtime

API affectées

Configuration et déploiement

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

Détails

La gestion des versions de produit a changé depuis les mises en production précédentes du .NET Framework, notamment par rapport à .NET Framework 4, 4.5, 4.5.1 et 4.5.2. Voici le détail des modifications :

  • La valeur de l’entrée Version dans la clé HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full a été remplacée par 4.6.xxxxx pour .NET Framework 4.6 et ses versions intermédiaires, et par 4.7.xxxxx pour .NET Framework 4.7 et 4.7.1. Dans .NET Framework 4.5, 4.5.1 et 4.5.2, elle était au format 4.5.xxxxx.
  • La gestion de versions de produit et de fichier pour les fichiers du .NET Framework est passée de l’ancien schéma 4.0.30319.x au schéma 4.6.X.0 pour .NET Framework 4.6 et ses versions intermédiaires, et au schéma 4.7.X.0 pour .NET Framework 4.7 et 4.7.1. Pour voir ces nouvelles valeurs, cliquez avec le bouton droit sur un fichier, puis affichez ses propriétés.
  • Les attributs AssemblyFileVersionAttribute et AssemblyInformationalVersionAttribute pour les assemblys managés ont des valeurs Version au format 4.6.X.0 pour .NET Framework 4.6 et ses versions intermédiaires, et 4.7.X.0 pour .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 propriété Environment.Version retourne la chaîne de version fixe 4.0.30319.42000. Dans le .NET Framework 4, 4.5, 4.5.1 et 4.5.2, elle retourne les chaînes de version au format 4.0.30319.xxxxx (par exemple, « 4.0.30319.18010 »). Notez que nous ne recommandons pas que le code d’application prenne de nouvelles dépendances sur la propriété Environment.Version.

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

Suggestion

En général, les applications doivent s'appuyer sur les techniques recommandées pour la détection d'éléments tels que la version de runtime du .NET Framework et le répertoire d'installation :

Important

Le nom de la sous-clé est NET Framework Setup, et non .NET Framework Setup.

  • Pour déterminer le chemin d'accès du répertoire du Common Language Runtime du .NET Framework, appelez la méthode RuntimeEnvironment.GetRuntimeDirectory().
  • Pour obtenir la version du CLR, appelez la méthode RuntimeEnvironment.GetSystemVersion(). Pour .NET Framework 4 et ses versions intermédiaires (.NET Framework 4.5, 4.5.1, 4.5.2 ainsi que .NET Framework 4.6, 4.6.1, 4.6.2, 4.7 et 4.7.1), elle retourne la chaîne v4.0.30319.
Nom Valeur
Étendue Secondaire
Version 4.6
Type Runtime

API affectées

Non détectable via l’analyse des API.

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

Détails

Comme prévu, la clé de version définie dans le Registre (au niveau 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 doivent être mises à jour afin de comprendre que 4.6 est une nouvelle version possible et qui est compatible avec les précédentes versions 4.5.x.

Suggestion

Mettez à jour les applications qui cherchent à découvrir une installation de .NET Framework 4.5 en recherchant les clés de Registre 4.5 pour accepter également 4.6.

Nom Valeur
Étendue Edge
Version 4.6
Type Runtime

API affectées

Non détectable via l’analyse des API.

Windows Communication Foundation (WCF)

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

Détails

Le .NET Framework 4.6 ajoute TLS 1.1 et TLS 1.2 à la liste des protocoles WCF SSL par défaut. Quand .NET Framework 4.6 ou ultérieur est installé sur les ordinateurs client et serveur, TLS 1.2 est utilisé à des fins de 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 parviendra 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 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 ceci :

<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 Secondaire
Version 4.6
Type Runtime

API affectées

Non détectable via l’analyse des API.

Windows Presentation Foundation (WPF)

L’accès aux éléments sélectionnés d’un DataGrid WPF à partir d’un gestionnaire de l’événement UnloadingRow du DataGrid peut provoquer 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 System.Windows.Controls.Primitives.Selector.SelectedItem ou System.Windows.Controls.Primitives.MultiSelector.SelectedItems de DataGrid.

Suggestion

Ce problème a été corrigé dans .NET Framework 4.6 et vous pouvez le résoudre en effectuant la mise à niveau vers cette version du .NET Framework.

Nom Valeur
Étendue Secondaire
Version 4,5
Type Runtime

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 le .NET Framework 4.5, si vous appelez ListBox.Items.Refresh à partir du code alors que des éléments sont sélectionnés dans une System.Windows.Controls.ListBox, les éléments en question peuvent apparaître deux fois dans la liste. Un problème similaire se produit avec System.Windows.Controls.ListView et System.Windows.Controls.DataGrid. Ce problème a été résolu dans le .NET Framework 4.6.

Suggestion

Pour contourner ce problème, vous pouvez désélectionner programmatiquement les éléments avant d’appeler System.Windows.Data.CollectionView.Refresh(), puis les resélectionner une fois l’appel effectué. Étant donné que ce problème a été résolu dans le .NET Framework 4.6, vous pouvez également mettre à niveau votre version du .NET Framework.

Valeur
Portée Secondaire
Version 4,5
Type Runtime

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, mettre à niveau vers .NET Framework 4.6.2.

Nom Valeur
Étendue Secondaire
Version 4.6
Type Runtime

API affectées

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

Détails

L’appel de Move(Int32, Int32) ou de 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 imprévisible avec une sélection ultérieure ou la désélection d’éléments de System.Windows.Controls.ListBox.

Suggestion

L’appel de System.Collections.ObjectModel.Collection<T>.Remove(T) et de System.Collections.ObjectModel.Collection<T>.Insert(Int32, T) au lieu de Move(Int32, Int32) permet de contourner ce problème. Étant donné que ce problème a été résolu dans le .NET Framework 4.6, vous pouvez également mettre à niveau votre version du .NET Framework.

Nom Valeur
Étendue Secondaire
Version 4,5
Type Runtime

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

Un clic droit sur un en-tête de ligne de System.Windows.Controls.DataGrid sélectionné alors que plusieurs lignes sont sélectionnées fait que la sélection de System.Windows.Controls.DataGrid est réduite à cette seule ligne.

Suggestion

Ce problème a été corrigé dans .NET Framework 4.6 et vous pouvez le résoudre en effectuant la mise à niveau vers cette version du .NET Framework.

Nom Valeur
Étendue Edge
Version 4,5
Type Runtime

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 résoudre ce problème est disponible dans une version de maintenance de .NET Framework 4.5.2 (correctif cumulatif 3026376) ou via la mise à niveau vers .NET Framework 4.6

Nom Valeur
Étendue Majeure
Version 4.5.2
Type Runtime

API affectées

Non détectable via l’analyse des API.

La correction orthographique WPF dans les contrôles acceptant du texte ne fonctionne pas dans Windows 10 pour les langues qui ne figurent 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 WPF acceptant du texte, car les fonctionnalités de vérification orthographique de la plateforme sont disponibles seulement pour les langues présentes dans la liste des langues d’entrée. Dans Windows 10, quand une langue est ajoutée à la liste des claviers disponibles, Windows télécharge et installe automatiquement un package correspondant de fonctionnalités à la demande qui fournit les fonctionnalités de vérification orthographique. En ajoutant la langue à la liste des langues d'entrée, le vérificateur d'orthographe est pris en charge.

Suggestion

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

Nom Valeur
Étendue Edge
Version 4.6
Type Runtime

API affectées

Non détectable via l’analyse des API.

Les fenêtres WPF sont restituées sans découpage lors de l’extension en dehors d’un même écran

Détails

Dans .NET Framework 4.6 s’exécutant sur Windows 8 et ultérieur, la totalité de la fenêtre est restituée sans découpage quand elle s’étend en dehors d’un même écran dans un scénario à plusieurs écrans. 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 Secondaire
Version 4.6
Type Runtime

API affectées

Non détectable via l’analyse des API.

.NET Framework 4.6.1

Outils

Contract.Invariant ou Contract.Requires<TException> ne considèrent pas String.IsNullOrEmpty comme pure

Détails

Pour les applications qui ciblent .NET Framework 4.6.1, si le contrat d’invariant de Contract.Invariant ou le contrat de condition préalable de Requires appelle la méthode String.IsNullOrEmpty, le module de réécriture émet l’avertissement CC1036 du compilateur : « 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 de celui-ci.

Suggestion

Ce comportement est abordé dans le problème 339, sur le site GitHub. Pour éviter cet avertissement, vous pouvez télécharger et compiler une version mise à jour du code source pour l’outil Contrats de code sur le site GitHub. Des informations sur le téléchargement se trouvent au bas de la page.

Nom Valeur
Étendue Secondaire
Version 4.6.1
Type Runtime

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

Quand un System.Windows.Controls.ItemsControl affiche une collection avec la virtualisation (IsVirtualizing=true) et le défilement d’éléments (ScrollUnit=Item), et quand le contrôle fait défiler pour afficher un élément dont la hauteur en pixels diffère de celle de ses voisins, le System.Windows.Controls.VirtualizingStackPanel effectue une itération 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, elle se produit lors du défilement de pixels (ScrollUnit=Pixel) quand un élément avec une hauteur en pixels différente est rencontré et lors du défilement d’éléments de données hiérarchiques (comme dans un System.Windows.Controls.TreeView ou un System.Windows.Controls.ItemsControl avec le regroupement activé) quand un élément avec un nombre d’éléments descendants différent de celui de ses voisins est rencontré. Pour le cas du défilement d’éléments et d’une hauteur en pixels différente, l’itération a été introduite dans le .NET Framework 4.6.1 pour corriger des bogues dans la présentation des données hiérarchiques. Elle n’est pas nécessaire si les données sont plates (pas de hiérarchie) et .NET Framework 4.6.2 ne l’effectue donc pas dans ce cas.

Suggestion

Si l’itération se produit dans .NET Framework 4.6.1 mais pas dans les versions antérieures, c’est-à-dire si System.Windows.Controls.ItemsControl effectue le défilement d’éléments d’une liste plate comportant des éléments avec des hauteurs en pixels différentes, vous avez deux solutions :

  • Installer .NET Framework 4.6.2
  • Installer le correctif HR 1605 pour .NET Framework 4.6.1
Nom Valeur
Étendue Secondaire
Version 4.6.1
Type Runtime

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. Ce problème est résolu dans .NET Framework 4.7 WPF via une gestion différente de l’exception, qui permet aux applications de ne plus en être affectée de cette façon. Notez que des exceptions occasionnelles continuent d’être observées dans les applications s’exécutant sous un débogueur.

Suggestion

Mettre à niveau vers .NET Framework 4.7

Nom Valeur
Étendue Edge
Version 4.6.1
Type Runtime

API affectées

Non détectable via l’analyse des API.

La correction orthographique dans WPF échoue de façon inattendue

Détails

Ceci inclut plusieurs problèmes du vérificateur orthographique de WPF :

  • Le vérificateur orthographique de WPF lève parfois System.Runtime.InteropServices.COMException
  • Le vérificateur orthographique de WPF échoue avec UnauthorizedAccessException quand les applications sont lancées avec « Exécuter en tant qu’autre utilisateur »
  • Le vérificateur orthographique de WPF identifie incorrectement des fautes d’orthographe dans les mots composés, comme « Hausnummer » en allemand.

Suggestion

Problème n° 1 : ce problème a été corrigé dans le .NET Framework 4.6.2. Problème n° 2 : le vérificateur orthographique de WPF n’est plus pris en charge quand les applications sont lancées avec « Exécuter en tant qu’autre utilisateur ». À compter du .NET Framework 4.6.2, les applications lancées de cette manière ne plantent plus de façon inattendue : à la place, le vérificateur orthographique est désactivé en mode silencieux. Problème n° 3 : ce problème a été corrigé dans le .NET Framework 4.6.2.

Nom Valeur
Étendue Edge
Version 4.6.1
Type Runtime

API affectées

Non détectable via l’analyse des 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, une tentative de connexion TCP/IP à une base de données SQL Server qui se résout en localhost échoue avec l’erreur « Une erreur liée au réseau ou spécifique à l’instance s’est produite lors de l’établissement d’une connexion au Serveur SQL. Le serveur est introuvable ou inaccessible. Vérifiez que le nom de l’instance est correct et que SQL Server est configuré pour autoriser les connexions à distance. (Fournisseur : interface réseau SQL, Erreur : 26 - Erreur lors de la localisation du serveur/de l’instance spécifiés) »

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 se résout en localhost, effectuez une mise à niveau vers .NET Framework 4.6.2.

Nom Valeur
Étendue Secondaire
Version 4.6
Type Runtime

API affectées

Non détectable via l’analyse des API.

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

Détails

À compter de .NET Framework 4.6.2, pour les demandes d’ouverture de connexion envoyées aux bases de données Azure SQL Database 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. Chaque nouvelle tentative de demande d’ouverture de connexion se produira presque immédiatement après les erreurs de connexion temporaires. Ce changement permet aux demandes d’ouverture de connexion d’être retentées immédiatement pour les bases de données Azure SQL Database, ce qui améliore les performances des applications 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, quand une application rencontre un échec temporaire durant la connexion à une base de données, la connexion ne peut pas être retentée rapidement, car le pool de connexions met l’erreur en cache, puis l’affiche de nouveau pendant une durée comprise entre 5 secondes et 1 minute. Pour plus d’informations, consultez Regroupement de connexions SQL Server (ADO.NET). Ce comportement pose problème pour les connexions aux bases de données SQL Azure, qui échouent souvent avec des erreurs temporaires, généralement rétablies au bout 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 période prolongée, même si la base de données est disponible et que l’application doit être affichée en quelques secondes.

Suggestion

Si ce comportement n’est pas souhaitable, la période de blocage du pool de connexions peut être configurée en définissant la propriété System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod introduite dans .NET Framework 4.6.2. La valeur de la propriété est un 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 affectant la valeur AlwaysBlock à la propriété System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod.

Nom Valeur
Étendue Secondaire
Version 4.6.2
Type Runtime

API affectées

Globalisation

Catégories de version Unicode standard 8.0 maintenant prises en charge

Détails

Dans .NET Framework 4.6.2, les données Unicode ont été mises à niveau de la version Unicode Standard 6.3 vers la version 8.0. Quand vous demandez des catégories de caractères Unicode dans .NET Framework 4.6.2, certains résultats peuvent ne pas correspondre à ceux 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 ou modifiez la logique qui varie selon les catégories de caractères Unicode codées en dur.

Nom Valeur
Étendue Secondaire
Version 4.6.2
Type Runtime

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, telles que System.Security.Cryptography.Xml.EncryptedXml) et System.Security.Cryptography.RSACng dans certains cas s’appuient sur la 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 de .NET Framework 4.6.2, CngLightup a été utilisé pour basculer vers System.Security.Cryptography.RSACng autant que 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 eu un impact négatif sur vos applications de confiance partielle, effectuez la mise à niveau vers .NET Framework 4.7.1.

Nom Valeur
Étendue Edge
Version 4.6.2
Type Runtime

API affectées

RSACng.VerifyHash retourne maintenant la valeur False pour tout échec de vérification

Détails

À compter de .NET Framework 4.6.2, cette méthode retourne False si le format de la signature proprement dite n’est pas correct. Elle retourne maintenant False pour tout échec de vérification. Dans .NET Framework 4.6 et 4.6.1, la méthode lève une System.Security.Cryptography.CryptographicException si le format de la signature proprement dite n’est pas correct.

Suggestion

Tout code dont l’exécution dépend de la gestion de System.Security.Cryptography.CryptographicException doit s’exécuter à la place si la validation échoue et que la méthode retourne False.

Nom Valeur
Étendue Secondaire
Version 4.6.2
Type Runtime

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 entraînent des comportements d’exécution différents. Par exemple :

  • Si un document contient plusieurs éléments avec le même attribut id et qu’une signature cible l’un de ces éléments comme 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.
  • N’importe quel programme tirant parti des signatures détachées des ressources externes ne pourra plus le faire.

Suggestion

Les développeurs peuvent examiner l’utilisation de XmlDsigXsltTransform et XmlDsigXsltTransform, ainsi que les types dérivés de Transform, car un destinataire du document risque de ne pas pouvoir le traiter.

Nom Valeur
Étendue Secondaire
Version 4.6.2
Type Runtime

API affectées

Windows Communication Foundation (WCF)

Suppression de Ssl3 de TransportDefaults dans WCF

Détails

Quand vous utilisez NetTcp avec la sécurité du transport et un type d’informations d’identification de certificat, le protocole SSL 3 n’est plus celui utilisé par défaut quand il s’agit de négocier une connexion sécurisée. Dans la majorité des cas, cela ne devrait pas avoir de conséquences sur les applications existantes, car TLS 1.0 a toujours figuré dans la liste de protocoles pour NetTcp. Tous les clients existants doivent pouvoir négocier une connexion en utilisant au moins TLS 1.0.

Suggestion

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

Nom Valeur
Étendue Edge
Version 4.6.2
Type Runtime

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 propriété System.Windows.UIElement.IsEnabled du parent d’un contrôle System.Windows.Controls.TextBlock affecte tous les contrôles enfants (comme les liens hypertexte et les boutons) du contrôle System.Windows.Controls.TextBlock. Dans le .NET Framework 4.6.1 et antérieur, les contrôles à l’intérieur d’une System.Windows.Controls.TextBlock ne reflétaient pas toujours l’état de la propriété System.Windows.UIElement.IsEnabled du parent de System.Windows.Controls.TextBlock.

Suggestion

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

Nom Valeur
Étendue Secondaire
Version 4.6.2
Type Runtime

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, mettre à niveau vers .NET Framework 4.6.2.

Nom Valeur
Étendue Secondaire
Version 4.6
Type Runtime

API affectées

DataGridCellsPanel.BringIndexIntoView lève une exception ArgumentOutOfRangeException

Détails

ScrollIntoView(Object) fonctionne de façon asynchrone quand 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 le travail asynchrone, une System.ArgumentOutOfRangeException peut se produire.

Suggestion

Effectuez une des actions suivantes :

  • Mise à niveau vers .NET Framework 4.7
  • Installation du dernier correctif pour .NET Framework 4.6.2
  • Évitez de supprimer des colonnes jusqu’à ce que la réponse asynchrone à ScrollIntoView(Object) soit effective.
Nom Valeur
Étendue Edge
Version 4.6.2
Type Runtime

API affectées

Défilement horizontal et virtualisation

Détails

Cette modification s’applique à un System.Windows.Controls.ItemsControl qui effectue sa propre virtualisation dans le sens orthogonal vers la direction de défilement principale (l’exemple classique est System.Windows.Controls.DataGrid avec EnableColumnVirtualization="True"). Le résultat de certaines opérations de défilement horizontal a été changé afin de produire des résultats qui sont plus intuitifs et plus analogues par rapport aux résultats des opérations verticales comparables.

Les opérations comprennent « Défilement ici » et « Bord droit » (il s’agit là des noms mentionnés dans le 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 le défilement vers le nouveau décalage, la notion de « ici » ou de « bord droit » peut avoir changé, car le nouveau contenu dévirtualisé a changé la valeur de System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth.

Avant .NET Framework 4.6.2, l’opération de défilement utilisait simplement le décalage candidat, même si ce n’est plus « ici » ou 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 a 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 avec HorizontalOffset=800, et le curseur « rebondit » à proximité du centre 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 déjà comme cela que le défilement vertical fonctionne.)

Le changement génère une expérience plus prévisible et intuitive pour l’utilisateur final, mais il peut aussi affecter toute application qui dépend de la valeur exacte de System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset après un défilement horizontal, qu’il s’agisse d’un appel explicite à SetHorizontalOffset(Double) ou d’un appel effectué par l’utilisateur final.

Suggestion

Une application qui utilise une valeur prédite pour System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset doit être changée afin de récupérer la valeur réelle (et la valeur de System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth) après un défilement horizontal susceptible de modifier System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth en raison de la dévirtualisation.

Nom Valeur
Étendue Secondaire
Version 4.6.2
Type Runtime

API affectées

Items.Clear ne supprime pas les doublons de SelectedItems

Détails

Supposons qu’un sélecteur (avec la sélection multiple activée) a des doublons dans sa collection System.Windows.Controls.Primitives.MultiSelector.SelectedItems - 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 supprimer de System.Windows.Controls.Primitives.MultiSelector.SelectedItems. Seule la première instance est supprimée. De plus, une utilisation ultérieure de System.Windows.Controls.Primitives.MultiSelector.SelectedItems (par exemple SelectedItems.Clear()) peut rencontrer des problèmes comme System.ArgumentException, car System.Windows.Controls.Primitives.MultiSelector.SelectedItems contient des éléments qui ne sont plus dans la source de données.

Suggestion

Si possible, mettez à niveau vers .NET Framework 4.6.2.

Nom Valeur
Étendue Secondaire
Version 4,5
Type Runtime

API affectées

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

Détails

Quand un System.Windows.Controls.ItemsControl affiche une collection avec la virtualisation (IsVirtualizing=true) et le défilement d’éléments (ScrollUnit=Item), et quand le contrôle fait défiler pour afficher un élément dont la hauteur en pixels diffère de celle de ses voisins, le System.Windows.Controls.VirtualizingStackPanel effectue une itération 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, elle se produit lors du défilement de pixels (ScrollUnit=Pixel) quand un élément avec une hauteur en pixels différente est rencontré et lors du défilement d’éléments de données hiérarchiques (comme dans un System.Windows.Controls.TreeView ou un System.Windows.Controls.ItemsControl avec le regroupement activé) quand un élément avec un nombre d’éléments descendants différent de celui de ses voisins est rencontré. Pour le cas du défilement d’éléments et d’une hauteur en pixels différente, l’itération a été introduite dans le .NET Framework 4.6.1 pour corriger des bogues dans la présentation des données hiérarchiques. Elle n’est pas nécessaire si les données sont plates (pas de hiérarchie) et .NET Framework 4.6.2 ne l’effectue donc pas dans ce cas.

Suggestion

Si l’itération se produit dans .NET Framework 4.6.1 mais pas dans les versions antérieures, c’est-à-dire si System.Windows.Controls.ItemsControl effectue le défilement d’éléments d’une liste plate comportant des éléments avec des hauteurs en pixels différentes, vous avez deux solutions :

  • Installer .NET Framework 4.6.2
  • Installer le correctif HR 1605 pour .NET Framework 4.6.1
Nom Valeur
Étendue Secondaire
Version 4.6.1
Type Runtime

API affectées

L’arrière-plan de RibbonGroup est défini sur Transparent dans les versions localisées

Détails

L’arrière-plan de System.Windows.Controls.Ribbon.RibbonGroup sur les versions localisées était toujours dessiné avec le pinceau Transparent, ce qui offrait une expérience assez pauvre de l’interface utilisateur. Ce point est résolu dans le correctif de .NET Framework 4.7 WPF par le biais d’une mise à jour des ressources localisées pour System.Windows.Controls.Ribbon.RibbonGroup, qui à son tour garantit que le bon pinceau est sélectionné.

Suggestion

Mettre à niveau vers .NET Framework 4.7

Nom Valeur
Étendue Edge
Version 4.6.2
Type Runtime

API affectées

Non détectable via l’analyse des API.

La correction orthographique dans WPF échoue de façon inattendue

Détails

Ceci inclut plusieurs problèmes du vérificateur orthographique de WPF :

  • Le vérificateur orthographique de WPF lève parfois System.Runtime.InteropServices.COMException
  • Le vérificateur orthographique de WPF échoue avec UnauthorizedAccessException quand les applications sont lancées avec « Exécuter en tant qu’autre utilisateur »
  • Le vérificateur orthographique de WPF identifie incorrectement des fautes d’orthographe dans les mots composés, comme « Hausnummer » en allemand.

Suggestion

Problème n° 1 : ce problème a été corrigé dans le .NET Framework 4.6.2. Problème n° 2 : le vérificateur orthographique de WPF n’est plus pris en charge quand les applications sont lancées avec « Exécuter en tant qu’autre utilisateur ». À compter du .NET Framework 4.6.2, les applications lancées de cette manière ne plantent plus de façon inattendue : à la place, le vérificateur orthographique est désactivé en mode silencieux. Problème n° 3 : ce problème a été corrigé dans le .NET Framework 4.6.2.

Nom Valeur
Étendue Edge
Version 4.6.1
Type Runtime

API affectées

Non détectable via l’analyse des API.