Partager via

Modifications de reciblage 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

HtmlTextWriter n’affiche pas correctement l’élément <br/>

Détails

À partir de .NET Framework 4.6, l’appel de RenderBeginTag(String) et de RenderEndTag() avec un élément <BR /> insère correctement un seul <BR /> (au lieu de deux)

Suggestion

Si une application dépendait de la balise <BR /> supplémentaire, RenderBeginTag(String) doit être appelé une deuxième fois. Notez que ce changement de comportement affecte uniquement les applications qui ciblent .NET Framework 4.6 ou les versions ultérieures. Vous pouvez donc également cibler une version antérieure du .NET Framework pour obtenir l’ancien comportement.

Nom Valeur
Étendue Edge
Version 4.6
Type Reciblage

API affectées

ClickOnce

Les applications publiées avec ClickOnce qui utilisent un certificat de signature de code SHA-256 peuvent échouer sur Windows 2003

Détails

L'exécutable est signé avec SHA256. Auparavant, il était signé avec SHA1, que le certificat de signature du code ait été SHA-1 ou SHA-256. Cela s’applique aux :

  • Toutes les applications générées avec Visual Studio 2012 ou ultérieur.
  • Toutes les applications générées avec Visual Studio 2010 ou antérieur en présence de .NET Framework 4.5. En outre, si .NET Framework 4.5 (ou une version ultérieure) est présent, le manifeste ClickOnce est également signé avec SHA-256 pour les certificats SHA-256, quelle que soit la version du .NET Framework sur laquelle il a été compilé.

Suggestion

Le changement de signature de l’exécutable ClickOnce affecte uniquement les systèmes Windows Server 2003. Vous devez installer le correctif logiciel KB 938397. Le changement de signature du manifeste avec l'algorithme SHA-256 même quand une application cible .NET Framework 4.0, ou des versions antérieures, présente une dépendance de runtime sur .NET Framework 4.5 ou version ultérieure.

Nom Valeur
Étendue Edge
Version 4,5
Type Reciblage

ClickOnce prend en charge SHA-256 sur les applications ciblées par la version 4.0

Détails

Avant, une application ClickOnce disposant d’un certificat signé avec SHA-256 nécessitait la présence de .NET Framework 4.5 ou ultérieur, même si l’application ciblait la version 4.0. Désormais, les applications ClickOnce ciblées par .NET Framework 4.0 peuvent s’exécuter sur .NET Framework 4.0, même si elles sont signées avec SHA-256.

Suggestion

Ce changement supprime cette dépendance et permet aux certificats SHA-256 d’être utilisés pour signer des applications ClickOnce qui ciblent .NET Framework 4 et les versions antérieures.

Nom Valeur
Étendue Secondaire
Version 4.6
Type Reciblage

Core

CurrentCulture et CurrentUICulture se propagent d’une tâche à l’autre

Détails

À compter de .NET Framework 4.6, System.Globalization.CultureInfo.CurrentCulture et System.Globalization.CultureInfo.CurrentUICulture sont stockés dans le System.Threading.ExecutionContext du thread, qui circulent d’une opération asynchrone à une autre. Cela signifie que les changements apportés à System.Globalization.CultureInfo.CurrentCulture ou System.Globalization.CultureInfo.CurrentUICulture sont reflétés dans des tâches qui sont exécutées de façon asynchrone par la suite. Cela diffère du comportement des précédentes versions du .NET Framework (qui réinitialisaient System.Globalization.CultureInfo.CurrentCulture et System.Globalization.CultureInfo.CurrentUICulture dans toutes les tâches asynchrones).

Suggestion

Si vos applications sont affectées par ce changement, vous pouvez le contourner en définissant explicitement le System.Globalization.CultureInfo.CurrentCulture ou System.Globalization.CultureInfo.CurrentUICulture souhaité comme première opération dans une tâche asynchrone. L’ancien comportement (qui ne transmet pas System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) peut également être adopté en définissant le commutateur de compatibilité suivant :

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Ce problème a été résolu par WPF dans le .NET Framework 4.6.2. Il a également été résolu dans .NET Framework versions 4.6 et 4.6.1 par le biais du correctif décrit dans l’article 3139549 de la Base de connaissances. Les applications qui ciblent .NET Framework 4.6 ou ultérieur obtiennent automatiquement le comportement approprié dans les applications WPF. System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture est conservé d’une opération de répartiteur à l’autre.

Nom Valeur
Étendue Secondaire
Version 4.6
Type Reciblage

API affectées

Les noms d’événements ETW ne peuvent pas différer uniquement par le suffixe « Start » ou « Stop »

Détails

Dans les versions 4.6 et 4.6.1 de .NET Framework, le runtime lève une ArgumentException lorsque deux noms d’événements ETW (Event Tracing for Windows) diffèrent uniquement par le suffixe Start ou Stop (comme lorsqu’un événement est nommé LogUser et un autre LogUserStart). Dans ce cas, le runtime ne peut pas construire la source d’événements, qui ne peut pas émettre de journalisation.

Suggestion

Pour empêcher cette exception, vérifiez qu’aucun des deux noms d’événement ne diffère uniquement par un suffixe Start ou Stop. À partir de .NET Framework 4.6.2, cette vérification n’est plus nécessaire. Le runtime est en mesure de lever l’ambiguïté relative aux noms d’événements qui diffèrent uniquement par les suffixes Start et Stop.

Nom Valeur
Étendue Edge
Version 4.6
Type Reciblage

Entity Framework

La génération d’un fichier edmx Entity Framework avec Visual Studio 2013 peut échouer avec l’erreur MSB4062 si vous utilisez les tâches EntityDeploySplit ou EntityClean

Détails

L’emplacement des fichiers des outils MSBuild 12.0 (inclus dans Visual Studio 2013) a changé, ce qui rend les anciens fichiers de cibles Entity Framework non valides. Les tâches EntityDeploySplit et EntityClean échouent, car elles ne parviennent pas à trouver Microsoft.Data.Entity.Build.Tasks.dll. Notez que ce problème est dû à un changement d’ensemble d’outils (MSBuild/VS), et non à un changement du .NET Framework. Il est dû à la mise à niveau des outils de développement, et non à celle du .NET Framework.

Suggestion

Les fichiers de cibles Entity Framework ont été corrigés pour fonctionner avec la nouvelle disposition MSBuild de .NET Framework 4.6. Vous pouvez résoudre ce problème en mettant à niveau votre .NET Framework vers la version 4.6. Vous pouvez également appliquer cette solution de contournement pour corriger directement les fichiers de cibles.

Nom Valeur
Étendue Majeure
Version 4.5.1
Type Reciblage

JIT

Instruction IL ret non autorisée dans une zone try

Détails

À la différence du compilateur juste-à-temps JIT 64 bits, RyuJIT (utilisé dans .NET Framework 4.6) n’autorise pas une instruction IL ret dans une zone try. Le retour à partir d’une zone try n’est pas autorisé par la spécification ECMA-335. Par ailleurs, aucun compilateur managé connu ne génère ce type de code IL. Toutefois, le compilateur JIT64 exécute ce code IL, s'il est généré à l'aide de l'émission de réflexion.

Suggestion

Si une application génère du code IL qui inclut un opcode ret dans une zone try, l’application peut cibler .NET Framework 4.5 pour utiliser l’ancien JIT et éviter cette interruption de l’exécution. Il est également possible de mettre à jour le code IL généré pour qu’il soit retourné après la zone try.

Nom Valeur
Étendue Edge
Version 4.6
Type Reciblage

Nouveau compilateur JIT 64 bits dans .NET Framework 4.6

Détails

À compter du .NET Framework 4.6, un nouveau compilateur JIT 64 bits est utilisé pour la compilation juste-à-temps. Dans certains cas, une exception inattendue est levée ou un comportement différent de celui obtenu quand l’application utilise le compilateur 32 bits ou le compilateur JIT 64 bits plus ancien est observé. Ce changement n’affecte pas le compilateur JIT 32 bits. Voici quelques-unes des différences connues :

  • Dans certaines conditions, une opération d’unboxing peut lever une NullReferenceException dans les versions Release avec l’optimisation activée.
  • Dans certains cas, l’exécution du code de production dans un corps de méthode volumineux peut lever une StackOverflowException.
  • Dans certaines conditions, les structures passées à une méthode sont traitées comme des types référence plutôt que comme des types valeur dans les versions Release. Ce problème se manifeste notamment lorsque des éléments dans une collection apparaissent dans un ordre inattendu.
  • Dans certaines conditions, la comparaison de valeurs UInt16 avec le bit le plus élevé est incorrecte si l’optimisation est activée.
  • Sous certaines conditions, en particulier lors de l’initialisation de tableaux de valeurs, l’initialisation de la mémoire par l’instruction OpCodes.Initblk du langage intermédiaire peut initialiser la mémoire avec une valeur incorrecte. Cela peut entraîner une exception non gérée ou une sortie incorrecte.
  • Dans certains cas rares, un test conditionnel binaire peut retourner une valeur Boolean incorrecte ou lever une exception si les optimisations du compilateur sont activées.
  • Sous certaines conditions, si une instruction if est utilisée pour tester une condition avant d’entrer dans un bloc try et dans la sortie du bloc try, et que la même condition est évaluée dans le bloc catch ou finally, le nouveau compilateur JIT 64 bits supprime la condition if du bloc catch ou finally lorsqu’il optimise le code. Par conséquent, le code à l’intérieur de l’instruction if dans le bloc catch ou finally est exécuté de manière non conditionnelle.

Suggestion

Atténuation des problèmes connus
Si vous rencontrez les problèmes répertoriés ci-dessus, vous pouvez les traiter en procédant d’une des façons suivantes :

  • Mettez à niveau vers .NET Framework 4.6.2. Le nouveau compilateur 64 bits inclus avec .NET Framework 4.6.2 résout chacun de ces problèmes connus.

  • Assurez-vous que votre version de Windows est à jour en exécutant Windows Update. Les mises à jour de service pour .NET Framework 4.6 et 4.6.1 corrigent chacun de ces problèmes, à l’exception de NullReferenceException dans une opération d’unboxing.

  • Compilez avec l’ancien compilateur JIT 64 bits. Consultez la section Atténuation des autres problèmes pour plus d’informations sur cette procédure. Atténuation des autres problèmes
    Si vous rencontrez une autre différence de comportement entre le code compilé avec l’ancien compilateur JIT 64 bits et celui compilé avec le nouveau compilateur, ou entre les versions Debug et Release de votre application lorsque les deux sont compilées avec le nouveau compilateur JIT 64 bits, vous pouvez procéder comme suit pour compiler votre application avec l’ancien compilateur JIT 64 bits :

  • Pour chaque application le nécessitant, vous pouvez ajouter l’élément < dans le fichier de configuration de votre application. Ce qui suit désactive la compilation avec le nouveau compilateur JIT 64 bits et utilise l’ancien compilateur à la place.

    <?xml version ="1.0"?>
<configuration>
  <runtime>
   <useLegacyJit enabled="1" />
  </runtime>
</configuration>

  • Pour chaque utilisateur concerné, vous pouvez ajouter une valeur REG_DWORD nommée useLegacyJit à la clé de registre HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework. La valeur 1 active l’ancien compilateur JIT 64 bits ; la valeur 0 le désactive et active le nouveau compilateur JIT 64 bits.

  • Pour chaque machine concernée, vous pouvez ajouter une valeur REG_DWORD nommée useLegacyJit à la clé de registre HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework. La valeur 1 active l’ancien compilateur JIT 64 bits ; la valeur 0 le désactive et active le nouveau compilateur JIT 64 bits. Vous pouvez également nous indiquer votre problème en signalant un bogue sur Microsoft Connect.

Nom Valeur
Étendue Edge
Version 4.6
Type Reciblage

Mise en réseau

Validation de l’OID de l’utilisation améliorée de la clé (EKU) du certificat

Détails

À compter de .NET Framework 4.6, les classes SslStream ou ServicePointManager effectuent la validation de l’identificateur d’objet (OID) de l’utilisation améliorée de la clé (EKU). Une extension EKU (utilisation améliorée de la clé) est une collection d’identificateurs d’objet indiquant les applications qui utilisent la clé. La validation de l’OID d’utilisation améliorée de la clé (EKU) utilise des rappels de certificat distant pour garantir que le certificat distant a les OID corrects pour l’utilisation prévue.

Suggestion

Si ce changement n’est pas souhaitable, vous pouvez désactiver la validation de l’OID de l’utilisation améliorée de la clé (EKU) du certificat en ajoutant le commutateur suivant à l’élément <AppContextSwitchOverrides> du ` de votre fichier de configuration d’application :

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

Important

Ce paramètre est fourni dans le seul but d’assurer la compatibilité descendante. Son utilisation à d’autres fins n’est pas recommandée.

Nom Valeur
Étendue Secondaire
Version 4.6
Type Reciblage

API affectées

Seuls les protocoles TLS 1.0, 1.1 et 1.2 sont pris en charge dans System.Net.ServicePointManager et System.Net.Security.SslStream

Détails

À compter de .NET Framework 4.6, les classes ServicePointManager et SslStream ne peuvent utiliser que l’un des trois protocoles suivants : TLS 1.0, TLS 1.1 ou TLS 1.2. Le protocole SSL 3.0 et le chiffrement RC4 ne sont pas pris en charge.

Suggestion

L’atténuation recommandée consiste à mettre à niveau l’application côté serveur vers TLS 1.0, TLS 1.1 ou TLS 1.2. Si ce n'est pas possible, ou si les applications clientes sont interrompues, la classe System.AppContext peut être utilisée pour désactiver cette fonctionnalité de deux manières :

  • En définissant des commutateurs de compatibilité programmatiquement sur System.AppContext, comme expliqué ici.
  • En ajoutant la ligne suivante à la section <runtime> du fichier app.config :
<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=true"/>
Nom Valeur
Étendue Secondaire
Version 4.6
Type Reciblage

API affectées

TLS 1.x passe par défaut l’indicateur SCH_SEND_AUX_RECORD à l’API SCHANNEL sous-jacente

Détails

Quand vous utilisez TLS 1.x, le .NET Framework s’appuie sur l’API SCHANNEL Windows sous-jacente. À compter de .NET Framework 4.6, l’indicateur SCH_SEND_AUX_RECORD est passé par défaut à SCHANNEL. Cela amène SCHANNEL à fractionner les données à chiffrer en deux enregistrements distincts, le premier sous forme d’un octet unique et le second de n-1 octets. Dans de rares cas, la communication s’en trouve interrompue entre les clients et les serveurs existants qui supposent que les données résident dans un seul enregistrement.

Suggestion

Si ce changement interrompt la communication avec un serveur existant, vous pouvez désactiver l’envoi de l’indicateur SCH_SEND_AUX_RECORD et restaurer le comportement précédent qui ne divise pas les données en enregistrements distincts en ajoutant le commutateur suivant à l’élément <AppContextSwitchOverrides> de la section <runtime> du fichier de configuration de votre application :

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

Important

Ce paramètre est fourni dans le seul but d’assurer la compatibilité descendante. Son utilisation à d’autres fins n’est pas recommandée.

Nom Valeur
Étendue Edge
Version 4.6
Type Reciblage

API affectées

Windows Communication Foundation (WCF)

L’appel de CreateDefaultAuthorizationContext avec un argument Null a été modifié

Détails

L’implémentation de la valeur System.IdentityModel.Policy.AuthorizationContext retournée par un appel à System.IdentityModel.Policy.AuthorizationContext.CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) avec un argument authorizationPolicies null est maintenant différente dans .NET Framework 4.6.

Suggestion

Dans de rares cas, les applications WCF qui utilisent l'authentification personnalisée peuvent voir les différences de comportement. Dans ce cas, vous pouvez restaurer l’ancien comportement de deux manières :

  • Recompiler l'application pour cibler une version antérieure du .NET Framework autre que 4.6. Pour les services hébergés dans IIS, utilisez l'élément <httpRuntime targetFramework="x.x"> pour cibler une version antérieure du .NET Framework.

  • Ajoutez la ligne suivante à la section <appSettings> de votre fichier app.config :

    <add key="appContext.SetSwitch:Switch.System.IdentityModel.EnableCachedEmptyDefaultAuthorizationContext" value="true" />
Nom Valeur
Étendue Secondaire
Version 4.6
Type Reciblage

API affectées

Windows Forms

Icon.ToBitmap convertit correctement les icônes dotées de cadres PNG en objets Bitmap

Détails

À compter des applications qui ciblent .NET Framework 4.6, la méthode Icon.ToBitmap convertit correctement en objets Bitmap les icônes comportant des cadres PNG.

Dans les applications qui ciblent .NET Framework 4.5.2 et versions antérieures, la méthode Icon.ToBitmap lève une exception ArgumentOutOfRangeException si l’objet Icon comporte des cadres PNG.

Ce changement affecte les applications qui sont recompilées pour cibler .NET Framework 4.6 et qui implémentent un traitement spécial pour l’exception ArgumentOutOfRangeException qui est levée quand un objet Icon comporte des cadres PNG. Dans le cadre d’une exécution sous le .NET Framework 4.6, la conversion aboutit, il n’est plus levé d’exception ArgumentOutOfRangeException et, de ce fait, le gestionnaire d’exceptions n’est plus appelé.

Suggestion

Si ce comportement est indésirable, vous pouvez conserver le comportement précédent en ajoutant l’élément suivant à la section <runtime> de votre fichier app.config :

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true" />

Si le fichier app.config contient déjà l’élément AppContextSwitchOverrides, la nouvelle valeur doit être fusionnée avec l’attribut value comme ceci :

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true;<previous key>=<previous value>" />
Nom Valeur
Étendue Secondaire
Version 4.6
Type Reciblage

API affectées

Windows Presentation Foundation (WPF)

CurrentCulture n’est pas conservé d’une opération de répartiteur WPF à l’autre

Détails

À compter du .NET Framework 4.6, les changements apportés à System.Globalization.CultureInfo.CurrentCulture ou System.Globalization.CultureInfo.CurrentUICulture dans un System.Windows.Threading.Dispatcher sont perdus à la fin de l’opération de ce répartiteur. De même, les changements apportés à System.Globalization.CultureInfo.CurrentCulture ou System.Globalization.CultureInfo.CurrentUICulture en dehors d’une opération de répartiteur peuvent ne pas être reflétés quand cette opération s’exécute. Concrètement, cela signifie que les changements System.Globalization.CultureInfo.CurrentCulture et System.Globalization.CultureInfo.CurrentUICulture peuvent ne pas circuler entre les rappels d’IU WPF et tout autre code dans une application WPF. Cela est dû à un changement dans System.Threading.ExecutionContext qui provoque le stockage de System.Globalization.CultureInfo.CurrentCulture et de System.Globalization.CultureInfo.CurrentUICulture dans le contexte d’exécution à compter des applications ciblant le .NET Framework 4.6. Les opérations de répartiteur WPF stockent le contexte d’exécution utilisé pour commencer l’opération et restaurer le contexte précédent lorsque l’opération est terminée. Étant donné que System.Globalization.CultureInfo.CurrentCulture et System.Globalization.CultureInfo.CurrentUICulture font désormais partie de ce contexte, les modifications qui leur sont apportées dans une opération de répartiteur ne sont pas conservées en dehors de cette opération.

Suggestion

Si vos applications sont affectées par ce changement, vous pouvez le contourner en stockant la valeur System.Globalization.CultureInfo.CurrentCulture ou System.Globalization.CultureInfo.CurrentUICulture souhaitée dans un champ, puis en vérifiant dans tous les corps d’opérations de répartiteur (notamment les gestionnaires de rappels d’événements de l’interface utilisateur) que les bons System.Globalization.CultureInfo.CurrentCulture et System.Globalization.CultureInfo.CurrentUICulture sont définis. Étant donné que le changement d’ExecutionContext sous-jacent à ce changement WPF affecte uniquement les applications qui ciblent le .NET Framework 4.6 ou ultérieur, vous pouvez éviter le problème en ciblant le .NET Framework 4.5.2. Pour les applications qui ciblent le .NET Framework 4.6 ou ultérieur, vous pouvez également contourner ce changement en définissant le commutateur de compatibilité suivant :

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Ce problème a été résolu par WPF dans le .NET Framework 4.6.2. Il a également été résolu dans .NET Framework versions 4.6 et 4.6.1 par le biais du correctif décrit dans l’article 3139549 de la Base de connaissances. Les applications qui ciblent .NET Framework 4.6 ou ultérieur obtiennent automatiquement le comportement approprié dans les applications WPF. System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture est conservé d’une opération de répartiteur à l’autre.

Nom Valeur
Étendue Secondaire
Version 4.6
Type Reciblage

L’arrondi des marges dans la disposition WPF a changé

Détails

La façon dont les marges sont arrondies, les bordures et l'arrière-plan ont changé. Résultat de cette modification :

  • La largeur ou la hauteur d'éléments peut croître ou diminuer d'un pixel au plus.
  • La position d'un objet peut se déplacer d'un pixel au plus.
  • Les éléments centrés peuvent être décalés verticalement ou horizontalement d'un pixel au plus. Par défaut, cette nouvelle disposition est activée uniquement pour les applications qui ciblent le .NET. Framework 4.6.

Suggestion

Dans la mesure où cette modification tend à éliminer le découpage droit ou inférieur des contrôles WPF dont le PPP est élevé, les applications qui ciblent les versions antérieures du .NET Framework, mais qui s'exécutent sur le .NET Framework 4.6, peuvent choisir ce nouveau comportement en ajoutant la ligne suivante à la section <runtime> du fichier app.config :

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=false" />

Les applications qui ciblent .NET Framework 4.6, mais veulent que les contrôles WPF soient rendus à l’aide de l’algorithme de disposition précédent peuvent y parvenir en ajoutant la ligne suivante à la section <runtime> du fichier app.config :

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=true" />
Nom Valeur
Étendue Secondaire
Version 4.6
Type Reciblage

XML, XSLT

XmlWriter lève des paires de substitution non valides

Détails

Pour les applications qui ciblent .NET Framework 4.5.2 ou les versions antérieures, l’écriture d’une paire de substitution non valide à l’aide de la gestion des exceptions de secours ne lève pas toujours une exception. Pour les applications qui ciblent .NET Framework 4.6, toute tentative d’écriture d’une paire de substitution non valide lève une System.ArgumentException.

Suggestion

Si nécessaire, vous pouvez éviter cette interruption en ciblant le .NET Framework 4.5.2 ou antérieur. Vous pouvez également prétraiter les paires de substitution non valides en code XML valide avant de les écrire.

Nom Valeur
Étendue Edge
Version 4.6
Type Reciblage

API affectées

La validation de schéma XSD détecte désormais les violations de contraintes uniques si des clés composées sont utilisées et que l’une d’elles est vide

Détails

Les versions du .NET Framework antérieures à 4.6 contenaient un bogue qui empêchait la validation XSD de détecter les contraintes uniques des clés composées si l’une d’elles était vide. Dans le .NET Framework 4.6, ce problème est résolu. La validation est désormais plus précise. Toutefois, il se peut que du code XML ne soit plus validé, alors qu’il l’était dans les versions précédentes.

Suggestion

Si une validation moins précise du .NET Framework 4.0 est nécessaire, l’application de validation peut cibler la version 4.5 (ou antérieure) du .NET Framework. Toutefois, quand vous reciblez vers .NET Framework 4.6, effectuez une revue du code pour vérifier que les clés composées en double (comme décrit plus haut) ne sont pas censées être validées.

Nom Valeur
Étendue Edge
Version 4.6
Type Reciblage

.NET Framework 4.6.1

Principal

Changement du caractère séparateur de chemin dans la propriété FullName des objets ZipArchiveEntry

Détails

Pour les applications qui ciblent .NET Framework 4.6.1 et versions ultérieures, le caractère de séparation de chemin a changé : la barre oblique inverse (« \ ») a été remplacée par la barre oblique (« / ») dans la propriété FullName des objets ZipArchiveEntry créés par les surcharges de la méthode CreateFromDirectory. L’implémentation .NET est ainsi conforme à la section 4.4.17.1 des Spécifications relatives au format des fichiers ZIP et permet aux archives ZIP d’être décompressées sur des systèmes non Windows.
La décompression d’un fichier zip créé par une application qui cible une version antérieure du .NET Framework sur les systèmes d’exploitation non-Windows, tels que les ordinateurs Macintosh, ne permet pas de conserver la structure de répertoire. Par exemple, pour les ordinateurs Macintosh, elle crée un ensemble de fichiers dont le nom concatène le chemin d’accès au répertoire, ainsi que toute barre oblique inverse (« \ »), et le nom de fichier. Par conséquent, la structure de répertoires des fichiers décompressés n’est pas conservée.

Suggestion

L’impact de ce changement sur les fichiers .ZIP qui sont décompressés dans le système d’exploitation Windows par les API de l’espace de noms System.IO de .NET Framework doit être minime, étant donné que ces API peuvent gérer sans problème aussi bien une barre oblique (« / ») qu’une barre oblique inverse (« \ ») comme caractère de séparation de chemin.
Si ce changement n’est pas souhaitable, vous pouvez choisir de l’annuler en ajoutant un paramètre de configuration à la section <runtime> du fichier de configuration de votre application. L’exemple suivant montre la section <runtime> et l’option d’annulation Switch.System.IO.Compression.ZipFile.UseBackslash :

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=true" />
</runtime>

De plus, les applications qui ciblent des versions antérieures du .NET Framework mais qui s’exécutent sur .NET Framework 4.6.1 ou ultérieur peuvent accepter ce comportement en ajoutant un paramètre de configuration à la section <runtime> du fichier de configuration de l’application. L’exemple suivant montre la section <runtime> et l’option d’activation Switch.System.IO.Compression.ZipFile.UseBackslash.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=false" />
</runtime>
Nom Valeur
Étendue Edge
Version 4.6.1
Type Reciblage

API affectées

Windows Communication Foundation (WCF)

Liaison WCF avec le mode de sécurité TransportWithMessageCredential

Détails

À partir de .NET Framework 4.6.1, les liaisons WCF qui utilisent le mode de sécurité TransportWithMessageCredential peuvent être configurées pour recevoir des messages avec des en-têtes « to » non signés pour les clés de sécurité asymétriques. Par défaut, les en-têtes « to » non signés continueront à être rejetés dans .NET Framework 4.6.1. Ils seront acceptés uniquement si une application accepte ce nouveau mode de fonctionnement en utilisant le commutateur de configuration Switch.System.ServiceModel.AllowUnsignedToHeader.

Suggestion

Parce qu’il s’agit d’une fonctionnalité d’abonnement, le comportement des applications existantes ne devrait pas être affecté.
Pour contrôler si le nouveau comportement est utilisé ou non, utilisez le paramètre de configuration suivant :

<runtime>
  <AppContextSwitchOverrides value="Switch.System.ServiceModel.AllowUnsignedToHeader=true" />
</runtime>
Nom Valeur
Étendue Mode transparent
Version 4.6.1
Type Reciblage

API affectées

X509CertificateClaimSet.FindClaims prend en compte tous les claimTypes

Détails

Dans les applications qui ciblent .NET Framework 4.6.1, si un ensemble de revendications X509 est initialisé à partir d’un certificat dont le champ SAN a plusieurs entrées DNS, la méthode System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) tente de faire correspondre l’argument claimType avec toutes les entrées DNS. Pour les applications qui ciblent des versions antérieures du .NET Framework, la méthode System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) tente de faire correspondre l’argument claimType uniquement avec la dernière entrée DNS.

Suggestion

Cette modification affecte uniquement les applications qui ciblent le .NET Framework 4.6.1. Elle peut être désactivée (ou activée si vous ciblez une version antérieure à 4.6.1) avec le commutateur de compatibilité DisableMultipleDNSEntries.

Nom Valeur
Étendue Secondaire
Version 4.6.1
Type Reciblage

API affectées

Windows Forms

Application.FilterMessage ne lève plus d’exception pour les implémentations réentrantes d’IMessageFilter.PreFilterMessage

Détails

Avant .NET Framework 4.6.1, le fait d’appeler FilterMessage(Message) avec un PreFilterMessage(Message) qui appelait System.Windows.Forms.Application.AddMessageFilter(IMessageFilter) ou System.Windows.Forms.Application.RemoveMessageFilter(IMessageFilter) (tout en appelant également DoEvents()) levait une exception System.IndexOutOfRangeException.

Dans les applications qui ciblent .NET Framework 4.6.1, cette exception n’est plus levée, et des filtres réentrants comme ceux décrits plus haut peuvent être utilisés.

Suggestion

Sachez que FilterMessage(Message) ne lève plus d’exception pour le comportement PreFilterMessage(Message) réentrant décrit ci-dessus. Ce changement affecte uniquement les applications qui ciblent le .NET Framework 4.6.1. Ces applications peuvent refuser ce changement (tandis que celles qui ciblent des versions antérieures du .NET Framework peuvent l’accepter) à l’aide du commutateur de compatibilité DontSupportReentrantFilterMessage.

Nom Valeur
Étendue Edge
Version 4.6.1
Type Reciblage

API affectées

Windows Presentation Foundation (WPF)

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

Détails

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

Suggestion

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

Nom Valeur
Étendue Edge
Version 4.6.1
Type Reciblage

.NET Framework 4.6.2

ASP.NET

HttpRuntime.AppDomainAppPath lève une exception NullReferenceException

Détails

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

Suggestion

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

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

API affectées

Core

Le déchiffreur AesCryptoServiceProvider fournit une transformation réutilisable

Détails

À partir des applications qui ciblent .NET Framework 4.6.2, le déchiffreur AesCryptoServiceProvider fournit une transformation réutilisable. Après un appel à System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32), la transformation est réinitialisée et peut être réutilisée. Pour les applications qui ciblent des versions antérieures du .NET Framework, toute tentative de réutilisation du déchiffreur en appelant System.Security.Cryptography.CryptoAPITransform.TransformBlock(Byte[], Int32, Int32, Byte[], Int32) après un appel à System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32) lève un CryptographicException ou génère des données endommagées.

Suggestion

L’impact de ce changement devrait être minime, car il s’agit du comportement attendu. Les applications qui dépendent du comportement précédent peuvent refuser le changement en ajoutant le paramètre de configuration suivant dans la section <runtime> du fichier de configuration de l’application :

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

De plus, les applications qui ciblent une version antérieure du .NET Framework mais qui s’exécutent dans .NET Framework 4.6.2 ou une version ultérieure peuvent accepter ce changement en ajoutant le paramètre de configuration suivant à la section <runtime> du fichier de configuration de l’application :

<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=false"/>
</runtime>
Nom Valeur
Étendue Secondaire
Version 4.6.2
Type Reciblage

API affectées

appels aux constructeurs ClaimsIdentity

Détails

À compter de .NET Framework 4.6.2, la façon dont les constructeurs ClaimsIdentity avec un paramètre System.Security.Principal.IIdentity définissent la propriété System.Security.Claims.ClaimsIdentity.Actor est modifiée. Si l’argument System.Security.Principal.IIdentity est un objet ClaimsIdentity et que la propriété System.Security.Claims.ClaimsIdentity.Actor de cet objet ClaimsIdentity n’est pas null, la propriété System.Security.Claims.ClaimsIdentity.Actor est attachée à l’aide de la méthode Clone(). Dans Framework 4.6.1 et les versions antérieures, la propriété System.Security.Claims.ClaimsIdentity.Actor est jointe comme une référence existante. En raison de ce changement, à compter de .NET Framework 4.6.2, la propriété System.Security.Claims.ClaimsIdentity.Actor du nouvel objet ClaimsIdentity n’est pas égale à la propriété System.Security.Claims.ClaimsIdentity.Actor de l’argument System.Security.Principal.IIdentity du constructeur. Dans .NET Framework 4.6.1 et les versions antérieures, elle est égale.

Suggestion

Si ce comportement n’est pas souhaitable, vous pouvez restaurer le comportement précédent en réglant Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity dans votre fichier de configuration d’application sur true. Pour cela, vous ajoutez le code suivant à la section <runtime> de votre fichier web.config :

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity=true" />
  </runtime>
</configuration>
Nom Valeur
Étendue Edge
Version 4.6.2
Type Reciblage

API affectées

Changements dans la normalisation des chemins

Détails

À partir des applications qui ciblent .NET Framework 4.6.2, la façon dont le runtime normalise les chemins a changé. La normalisation d’un chemin implique la modification de la chaîne qui identifie un chemin ou un fichier afin qu’elle soit conforme à un chemin valide sur le système d’exploitation cible. La normalisation implique généralement :

  • La mise en forme canonique des composants et séparateurs de répertoires.
  • L’application du répertoire actuel à un chemin d’accès relatif.
  • L’évaluation du répertoire relatif (.) ou du répertoire parent (..) dans un chemin.
  • La suppression des caractères spécifiés. À partir des applications qui ciblent .NET Framework 4.6.2, les changements suivants apportés à la normalisation des chemins sont activés par défaut :
    • Le runtime défère à la fonction GetFullPathName du système d’exploitation pour normaliser les chemins d’accès.
  • La normalisation n’implique plus la suppression de la fin des segments de répertoire (comme un espace à la fin d’un nom de répertoire).
  • Prise en charge de la syntaxe du chemin d’appareil avec une confiance totale, y compris \\.\ et, pour les API d’E/S de fichiers dans mscorlib.dll, \\?\.
  • Le runtime ne valide pas les chemins d’accès de syntaxe de périphérique.
  • L’utilisation de la syntaxe de périphérique pour accéder aux autres flux de données est prise en charge. Ces modifications améliorent les performances tout en permettant aux méthodes d’accéder à des chemins auparavant inaccessibles. Les applications qui ciblent .NET Framework 4.6.1 et les versions antérieures, mais s’exécutent sur .NET Framework 4.6.2 ou une version ultérieure ne sont pas concernées par ce changement.

Suggestion

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

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

Les applications qui ciblent .NET Framework 4.6.1 ou une version antérieure mais qui s’exécutent sur .NET Framework 4.6.2 ou une version ultérieure peuvent activer les changements apportées à la normalisation des chemins en ajoutant la ligne suivante à la section <runtime> du fichier de configuration d’application :

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false" />
</runtime>
Nom Valeur
Étendue Secondaire
Version 4.6.2
Type Reciblage

CurrentCulture et CurrentUICulture se propagent d’une tâche à l’autre

Détails

À compter de .NET Framework 4.6, System.Globalization.CultureInfo.CurrentCulture et System.Globalization.CultureInfo.CurrentUICulture sont stockés dans le System.Threading.ExecutionContext du thread, qui circulent d’une opération asynchrone à une autre. Cela signifie que les changements apportés à System.Globalization.CultureInfo.CurrentCulture ou System.Globalization.CultureInfo.CurrentUICulture sont reflétés dans des tâches qui sont exécutées de façon asynchrone par la suite. Cela diffère du comportement des précédentes versions du .NET Framework (qui réinitialisaient System.Globalization.CultureInfo.CurrentCulture et System.Globalization.CultureInfo.CurrentUICulture dans toutes les tâches asynchrones).

Suggestion

Si vos applications sont affectées par ce changement, vous pouvez le contourner en définissant explicitement le System.Globalization.CultureInfo.CurrentCulture ou System.Globalization.CultureInfo.CurrentUICulture souhaité comme première opération dans une tâche asynchrone. L’ancien comportement (qui ne transmet pas System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) peut également être adopté en définissant le commutateur de compatibilité suivant :

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Ce problème a été résolu par WPF dans le .NET Framework 4.6.2. Il a également été résolu dans .NET Framework versions 4.6 et 4.6.1 par le biais du correctif décrit dans l’article 3139549 de la Base de connaissances. Les applications qui ciblent .NET Framework 4.6 ou ultérieur obtiennent automatiquement le comportement approprié dans les applications WPF. System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture est conservé d’une opération de répartiteur à l’autre.

Nom Valeur
Étendue Secondaire
Version 4.6
Type Reciblage

API affectées

Les noms d’événements ETW ne peuvent pas différer uniquement par le suffixe « Start » ou « Stop »

Détails

Dans les versions 4.6 et 4.6.1 de .NET Framework, le runtime lève une ArgumentException lorsque deux noms d’événements ETW (Event Tracing for Windows) diffèrent uniquement par le suffixe Start ou Stop (comme lorsqu’un événement est nommé LogUser et un autre LogUserStart). Dans ce cas, le runtime ne peut pas construire la source d’événements, qui ne peut pas émettre de journalisation.

Suggestion

Pour empêcher cette exception, vérifiez qu’aucun des deux noms d’événement ne diffère uniquement par un suffixe Start ou Stop. À partir de .NET Framework 4.6.2, cette vérification n’est plus nécessaire. Le runtime est en mesure de lever l’ambiguïté relative aux noms d’événements qui diffèrent uniquement par les suffixes Start et Stop.

Nom Valeur
Étendue Edge
Version 4.6
Type Reciblage

Prise en charge des chemins d’accès longs

Détails

À partir des applications qui ciblent .NET Framework 4.6.2, les chemins longs (comprenant jusqu’à 32 000 caractères) sont pris en charge et la limite de 260 caractères (ou MAX_PATH) sur la longueur du chemin est supprimée. Pour les applications qui sont recompilées pour cibler .NET Framework 4.6.2, les chemins de code qui levaient précédemment un System.IO.PathTooLongException car un chemin dépassait 260 caractères lèvent désormais un System.IO.PathTooLongException uniquement quand les conditions suivantes sont remplies :

  • La longueur du chemin est supérieure à MaxValue (32 767) caractères.
  • Le système d’exploitation renvoie COR_E_PATHTOOLONG ou son équivalent. Pour les applications qui ciblent .NET Framework 4.6.1 et les versions antérieures, le runtime levait automatiquement un System.IO.PathTooLongException chaque fois qu’un chemin comportait plus de 260 caractères.

Suggestion

Pour les applications qui ciblent .NET Framework 4.6.2, vous pouvez refuser la prise en charge des chemins longs en ajoutant le code suivant à la section <runtime> de votre fichier app.config :

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

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

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=false" />
</runtime>
Nom Valeur
Étendue Secondaire
Version 4.6.2
Type Reciblage

Les vérifications des signes deux-points dans les chemins d’accès sont plus strictes

Détails

Dans .NET Framework 4.6.2, un certain nombre de modifications ont été apportées pour prendre en charge les chemins d’accès précédemment non pris en charge (à la fois en termes de longueur et de format). Les vérifications de la syntaxe appropriée du séparateur de lecteur (deux-points) ont été affinées, ce qui a eu pour effet secondaire de bloquer certains chemins d’URI dans quelques API de chemin spécifiques où ils étaient auparavant tolérés.

Suggestion

Si vous passez un URI à des API affectées, modifiez d’abord la chaîne pour en faire un chemin valide.

  • Supprimez manuellement le schéma des URL (par exemple, supprimez file:// de celles-ci).

  • Transmettez l’URI à la classe Uri et utilisez LocalPath.

Vous pouvez également refuser la nouvelle normalisation de chemin en définissant le commutateur AppContext Switch.System.IO.UseLegacyPathHandling sur true.

Nom Valeur
Étendue Edge
Version 4.6.2
Type Reciblage

API affectées

Sécurité

L’algorithme RSACng charge désormais correctement les clés RSA de taille de clé non standard

Détails

Dans les versions .NET Framework antérieures à la version 4.6.2, les clients avec des tailles de clé non standard pour les certificats RSA ne peuvent pas accéder à ces clés via les méthodes d’extension System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(X509Certificate2) et System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(X509Certificate2). Une System.Security.Cryptography.CryptographicException comportant le message « la taille de clé demandée n’est pas prise en charge » est générée. Dans .NET Framework 4.6.2, ce problème a été résolu. De même, ImportParameters(RSAParameters) et ImportParameters(RSAParameters) fonctionnent désormais avec des tailles de clé non standard sans lever d’exception System.Security.Cryptography.CryptographicException.

Suggestion

S’il existe une logique de gestion des exceptions qui s’appuie sur le comportement précédent où un System.Security.Cryptography.CryptographicException est levé quand des tailles de clé non standard sont utilisées, supprimez la logique.

Nom Valeur
Étendue Edge
Version 4.6.2
Type Reciblage

API affectées

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

Détails

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

Suggestion

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

<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.SignedXmlUseLegacyCertificatePrivateKey=true" />
Nom Valeur
Étendue Edge
Version 4.6.2
Type Reciblage

API affectées

Windows Communication Foundation (WCF)

Un blocage peut se produire lors de l’utilisation de services réentrants

Détails

Un blocage peut survenir dans un service réentrant, ce qui limite les instances du service à un thread d’exécution à la fois. Les services susceptibles de rencontrer ce problème ont le ServiceBehaviorAttribute suivant dans leur code :

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]

Suggestion

Pour résoudre ce problème, vous pouvez effectuer l’opération suivante :

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]
  • Installez la dernière mise à jour sur .NET Framework 4.6.2 ou effectuez une mise à niveau vers une version ultérieure du .NET Framework. Cela désactive le flux de l’ExecutionContext dans OperationContext.Current. Ce comportement est configurable. Cela équivaut à ajouter le paramètre d’application suivant à votre fichier de configuration :
<appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
</appSettings>

La valeur de Switch.System.ServiceModel.DisableOperationContextAsyncFlow ne doit jamais être définie sur false pour les services réentrants.

Nom Valeur
Étendue Secondaire
Version 4.6.2
Type Reciblage

API affectées

OperationContext.Current peut retourner null en cas d’appel dans une clause using

Détails

OperationContext.Current peut retourner null et il peut en résulter un NullReferenceException si toutes les conditions suivantes sont remplies :

using (new OperationContextScope(OperationContext.Current))
{
    // OperationContext.Current is null.
    OperationContext context = OperationContext.Current;

    // ...
}

Suggestion

Pour résoudre ce problème, vous pouvez effectuer l’opération suivante :

  • Modifiez votre code comme suit pour instancier un nouvel objet Current non-null :

    OperationContext ocx = OperationContext.Current;
using (new OperationContextScope(OperationContext.Current))
{
    OperationContext.Current = new OperationContext(ocx.Channel);

    // ...
}

  • Installez la dernière mise à jour sur .NET Framework 4.6.2 ou effectuez une mise à niveau vers une version ultérieure du .NET Framework. Cela désactive le flux de ExecutionContext dans OperationContext.Current et restaure le comportement des applications WCF dans .NET Framework 4.6.1 et les versions antérieures. Ce comportement est configurable. Cela équivaut à ajouter le paramètre d’application suivant à votre fichier de configuration :

    <appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
</appSettings>

    Si ce changement n’est pas souhaitable et que votre application dépend du flux de contexte d’exécution entre les contextes d’opération, vous pouvez activer son flux comme suit :

    <appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="false" />
</appSettings>
Nom Valeur
Étendue Edge
Version 4.6.2
Type Reciblage

API affectées

La sécurité du transport WCF prend en charge les certificats stockés à l’aide de CNG

Détails

À partir des applications qui ciblent .NET Framework 4.6.2, la sécurité du transport WCF prend en charge les certificats stockés à l’aide de la bibliothèque de chiffrement Windows (CNG). Cette prise en charge se limite aux certificats avec une clé publique dont l’exposant ne dépasse pas 32 bits de longueur. Quand une application cible .NET Framework 4.6.2, cette fonctionnalité est activée par défaut. Dans les versions antérieures du .NET Framework, les tentatives d’utilisation de certificats X509 avec un fournisseur de stockage de clés CSG lèvent une exception.

Suggestion

Les applications qui ciblent .NET Framework 4.6.1 et les versions antérieures mais qui s’exécutent sur .NET Framework 4.6.2 peuvent activer la prise en charge des certificats CNG en ajoutant la ligne suivante à la section <runtime> du fichier app.config ou web.config :

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IdentityModel.DisableCngCertificates=false" />
</runtime>

Vous pouvez en faire autant par programmation avec un code de ce type :

private const string DisableCngCertificates = @"Switch.System.IdentityModel.DisableCngCertificate";

AppContext.SetSwitch(disableCngCertificates, false);

Const DisableCngCertificates As String = "Switch.System.IdentityModel.DisableCngCertificates"
AppContext.SetSwitch(disableCngCertificates, False)

Notez qu’en raison de cette modification, tout code de traitement des exceptions qui dépend de l’échec de la tentative d’établissement d’une communication sécurisée avec un certificat CNG ne s’exécutera plus.

Nom Valeur
Étendue Secondaire
Version 4.6.2
Type Reciblage

Windows Forms

Implémentation incorrecte de MemberDescriptor.Equals

Détails

L’implémentation d’origine de la méthode MemberDescriptor.Equals compare deux propriétés de chaîne différentes des objets comparés : le nom de la catégorie et la chaîne de description. La solution consiste à comparer Category du premier objet à Category du second, et Description du premier à Description du second.

Suggestion

Si votre application dépend de MemberDescriptor.Equals qui retourne parfois false quand les descripteurs sont équivalents et que vous ciblez .NET Framework 4.6.2 ou version ultérieure, plusieurs options s’offrent à vous :

  • Changez le code pour comparer manuellement les champs Category et Description parallèlement à l’appel de la méthode MemberDescriptor.Equals.
  • Refusez ce changement en ajoutant la valeur suivante au fichier app.config :
<runtime>
  <AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=true" />
</runtime>

Si votre application cible .NET Framework 4.6.1 ou version antérieure, qu’elle s’exécute sur .NET Framework 4.6.2 ou version ultérieure et que vous souhaitez activer ce changement, vous pouvez affecter false au commutateur de compatibilité en ajoutant la valeur suivante au fichier app.config :

<runtime>
  <AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=false" />
</runtime>
Nom Valeur
Étendue Edge
Version 4.6.2
Type Reciblage

API affectées

Windows Presentation Foundation (WPF)

CurrentCulture n’est pas conservé d’une opération de répartiteur WPF à l’autre

Détails

À compter du .NET Framework 4.6, les changements apportés à System.Globalization.CultureInfo.CurrentCulture ou System.Globalization.CultureInfo.CurrentUICulture dans un System.Windows.Threading.Dispatcher sont perdus à la fin de l’opération de ce répartiteur. De même, les changements apportés à System.Globalization.CultureInfo.CurrentCulture ou System.Globalization.CultureInfo.CurrentUICulture en dehors d’une opération de répartiteur peuvent ne pas être reflétés quand cette opération s’exécute. Concrètement, cela signifie que les changements System.Globalization.CultureInfo.CurrentCulture et System.Globalization.CultureInfo.CurrentUICulture peuvent ne pas circuler entre les rappels d’IU WPF et tout autre code dans une application WPF. Cela est dû à un changement dans System.Threading.ExecutionContext qui provoque le stockage de System.Globalization.CultureInfo.CurrentCulture et de System.Globalization.CultureInfo.CurrentUICulture dans le contexte d’exécution à compter des applications ciblant le .NET Framework 4.6. Les opérations de répartiteur WPF stockent le contexte d’exécution utilisé pour commencer l’opération et restaurer le contexte précédent lorsque l’opération est terminée. Étant donné que System.Globalization.CultureInfo.CurrentCulture et System.Globalization.CultureInfo.CurrentUICulture font désormais partie de ce contexte, les modifications qui leur sont apportées dans une opération de répartiteur ne sont pas conservées en dehors de cette opération.

Suggestion

Si vos applications sont affectées par ce changement, vous pouvez le contourner en stockant la valeur System.Globalization.CultureInfo.CurrentCulture ou System.Globalization.CultureInfo.CurrentUICulture souhaitée dans un champ, puis en vérifiant dans tous les corps d’opérations de répartiteur (notamment les gestionnaires de rappels d’événements de l’interface utilisateur) que les bons System.Globalization.CultureInfo.CurrentCulture et System.Globalization.CultureInfo.CurrentUICulture sont définis. Étant donné que le changement d’ExecutionContext sous-jacent à ce changement WPF affecte uniquement les applications qui ciblent le .NET Framework 4.6 ou ultérieur, vous pouvez éviter le problème en ciblant le .NET Framework 4.5.2. Pour les applications qui ciblent le .NET Framework 4.6 ou ultérieur, vous pouvez également contourner ce changement en définissant le commutateur de compatibilité suivant :

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Ce problème a été résolu par WPF dans le .NET Framework 4.6.2. Il a également été résolu dans .NET Framework versions 4.6 et 4.6.1 par le biais du correctif décrit dans l’article 3139549 de la Base de connaissances. Les applications qui ciblent .NET Framework 4.6 ou ultérieur obtiennent automatiquement le comportement approprié dans les applications WPF. System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture est conservé d’une opération de répartiteur à l’autre.

Nom Valeur
Étendue Secondaire
Version 4.6
Type Reciblage