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

Cet article répertorie les problèmes de compatibilité des applications qui ont été introduits dans .NET Framework 4.5, 4.5.1 et 4.5.2.

.NET Framework 4.5

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

• GridView.AllowCustomPaging

La propriété HttpRequest.ContentEncoding interdit UTF7

Détails

À compter de .NET Framework 4.5, l’encodage UTF-7 est interdit dans le corps des System.Web.HttpRequest. Les données des applications qui dépendent des données UTF-7 entrantes ne seront pas décodées correctement dans certains cas.

Suggestion

Dans l’idéal, les applications doivent être mises à jour pour ne pas utiliser l’encodage UTF-7 dans les System.Web.HttpRequest. Vous pouvez aussi restaurer le comportement hérité à l’aide de l’attribut aspnet:AllowUtf7RequestContentEncoding de l’élément appSettings.

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

• HttpRequest.ContentEncoding

HttpUtility.JavaScriptStringEncode place le caractère esperluette (&) dans une séquence d’échappement

Détails

Depuis .NET Framework 4.5, System.Web.HttpUtility.JavaScriptStringEncode(String) place le caractère esperluette (&) dans une séquence d’échappement.

Suggestion

Si votre application dépend du comportement précédent de cette méthode, vous pouvez ajouter un paramètre aspnet:JavaScriptDoNotEncodeAmpersand à l’élément appSettings ASP.NET dans votre fichier de configuration.

Nom	Valeur
Étendue	Secondaire
Version	4,5
Type	Runtime

API affectées

• HttpUtility.JavaScriptStringEncode(String)
• HttpUtility.JavaScriptStringEncode(String, Boolean)

IPad ne doit pas servir dans le fichier de fonctionnalités personnalisé, car il est désormais une fonctionnalité du navigateur

Détails

À compter de .NET Framework 4.5, iPad étant un identificateur dans le fichier de fonctionnalités du navigateur ASP.NET par défaut, il ne doit pas être utilisé dans un fichier de fonctionnalités personnalisé

Suggestion

Si des fonctionnalités spécifiques à l’iPad sont requises, il est nécessaire de modifier le comportement de l’iPad en définissant des fonctionnalités sur la passerelle prédéfinie refID « IPad » et non en générant un ID « IPad » par mise en correspondance de l’agent utilisateur.

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

L’événement Page.LoadComplete n’entraîne plus l’appel d’une liaison de données par le contrôle System.Web.UI.WebControls.EntityDataSource

Détails

L'événement LoadComplete ne force plus le contrôle System.Web.UI.WebControls.EntityDataSource à appeler une liaison de données pour les modifications dans le but de créer/mettre à jour/supprimer des paramètres. Cette modification supprime un aller-retour superflu vers la base de données, empêche la réinitialisation des valeurs des contrôles et produit un comportement cohérent avec les autres contrôles de données, tels que System.Web.UI.WebControls.SqlDataSource et System.Web.UI.WebControls.ObjectDataSource. Elle produit un comportement différent dans le cas peu probable où les applications dépendraient de l'appel de la liaison de données dans l'événement LoadComplete.

Suggestion

Si une liaison de données est nécessaire, appelez manuellement la méthode databind dans un événement situé plus haut dans la publication (postback).

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

Non détectable via l’analyse des API.

Le profilage des applications ASP.NET MVC4 peut entraîner une erreur irrécupérable du moteur d’exécution

Détails

Les profileurs qui utilisent des assemblys NGEN /profil peuvent planter des applications ASP.NET MVC4 profilées au démarrage avec une exception irrécupérable du moteur d’exécution

Suggestion

Ce problème a été résolu dans .NET Framework 4.5.2. Le profileur peut aussi éviter ce problème en spécifiant COR_PRF_DISABLE_ALL_NGEN_IMAGES dans son masque d’événement.

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

Non détectable via l’analyse des API.

Le partage de l’état de session avec ASP.NET StateServer nécessite que tous les serveurs de la batterie de serveurs web utilisent la même version du .NET Framework

Détails

Lors de l’activation de l’état de session System.Web.SessionState.SessionStateMode.StateServer, tous les serveurs dans la batterie de serveurs web donnée doivent utiliser la même version du .NET Framework pour que l’état soit correctement partagé.

Suggestion

Veillez à mettre à niveau les versions du .NET Framework sur les serveurs web qui partagent l’état en même temps.

	Valeur
Portée	Edge
Version	4,5
Type	Runtime

API affectées

• SessionStateMode.StateServer

WebUtility.HtmlDecode ne décode plus les séquences d’entrée non valides

Détails

Par défaut, les méthodes de décodage ne décodent plus une séquence d'entrée non valide en une chaîne UTF-16 non valide. Au lieu de cela, elles retournent l'entrée d'origine.

Suggestion

Le changement lié à la sortie du décodeur doit importer uniquement si vous stockez des données binaires à la place de données UTF-16 dans les chaînes. Pour contrôler explicitement ce comportement, affectez à l’attribut aspnet:AllowRelaxedUnicodeDecoding de l’élément appSettings la valeur true pour activer le comportement hérité ou la valeur false pour activer le comportement actuel.

	Valeur
Portée	Secondaire
Version	4,5
Type	Runtime

API affectées

• WebUtility.HtmlDecode(String)
• WebUtility.HtmlDecode(String, TextWriter)
• WebUtility.UrlDecode(String)

Core

Les assemblys compilés avec Regex.CompileToAssembly sont rompus entre 4.0 et 4.5

Détails

Si un assembly d’expressions régulières compilées est généré avec .NET Framework 4.5 mais qu’il cible .NET Framework 4, toute tentative d’utiliser l’une des expressions régulières dans cet assembly sur un système sur lequel .NET Framework 4 est installé lève une exception.

Suggestion

Pour contourner ce problème, vous pouvez procéder de l'une des manières suivantes :

• Générez l’assembly qui contient les expressions régulières avec .NET Framework 4.
• Utilisez une expression régulière interprétée.

Nom	Valeur
Étendue	Secondaire
Version	4,5
Type	Runtime

API affectées

• Regex.CompileToAssembly(RegexCompilationInfo[], AssemblyName)
• Regex.CompileToAssembly(RegexCompilationInfo[], AssemblyName, CustomAttributeBuilder[])
• Regex.CompileToAssembly(RegexCompilationInfo[], AssemblyName, CustomAttributeBuilder[], String)

BlockingCollection<T>.TryTakeFromAny ne lève plus d’exceptions

Détails

Si l’une des collections d’entrée est marquée comme terminée, TryTakeFromAny(BlockingCollection<T>[], T) ne retourne plus -1, et TakeFromAny(BlockingCollection<T>[], T) ne lève plus d’exceptions. Cette modification permet d'utiliser des collections lorsque l'une est vide ou terminée, alors que l'autre comporte toujours des éléments pouvant être récupérés.

Suggestion

Si vous utilisiez TryTakeFromAny pour retourner -1 ou TakeFromAny pour lever des exceptions à des fins de flux de contrôle, dans le contexte d’une collection bloquante terminée, ce code doit à présent être modifié pour utiliser .Any(b => b.IsCompleted) de manière à détecter cette condition.

Nom	Valeur
Étendue	Secondaire
Version	4,5
Type	Runtime

API affectées

• BlockingCollection<T>.TakeFromAny(BlockingCollection<T>[], T)
• BlockingCollection<T>.TakeFromAny(BlockingCollection<T>[], T, CancellationToken)
• BlockingCollection<T>.TryTakeFromAny(BlockingCollection<T>[], T)
• BlockingCollection<T>.TryTakeFromAny(BlockingCollection<T>[], T, Int32)
• BlockingCollection<T>.TryTakeFromAny(BlockingCollection<T>[], T, TimeSpan)
• BlockingCollection<T>.TryTakeFromAny(BlockingCollection<T>[], T, TimeSpan)

Changement de comportement des méthodes Task.WaitAll avec des arguments de délai d’attente

Détails

Le comportement de Task.WaitAll est devenu plus cohérent dans .NET Framework 4.5. Dans .NET Framework 4, le comportement de ces méthodes n’était pas cohérent. Lorsque le délai d'attente expirait, si une ou plusieurs tâches étaient terminées ou annulées avant l'appel de la méthode, la méthode levait une exception System.AggregateException. Lorsque le délai d’attente expirait, si aucune tâche n’était terminée ou annulée avant l’appel de la méthode alors qu’une ou plusieurs tâches adoptaient ces états après l’appel de la méthode, la méthode retournait la valeur false.

Dans .NET Framework 4.5, ces surcharges de méthode retournent désormais la valeur false si des tâches sont toujours en cours d’exécution quand l’intervalle de délai d’attente expire, et elles ne lèvent une exception System.AggregateException que si une tâche d’entrée a été annulée (que cette annulation soit intervenue avant ou après l’appel de méthode) et qu’aucune autre tâche n’est en cours d’exécution.

Suggestion

Si une exception System.AggregateException a été interceptée dans le but de détecter une tâche ayant été annulée avant l’appel de WaitAll, ce code doit procéder à la même détection par le biais de la propriété IsCanceled (par exemple : .Any(t => t.IsCanceled)), puisque .NET Framework 4.6 lève une exception seulement si toutes les tâches attendues sont terminées avant le délai d’attente.

	Valeur
Portée	Secondaire
Version	4,5
Type	Runtime

API affectées

• Task.WaitAll(Task[], Int32)
• Task.WaitAll(Task[], Int32, CancellationToken)
• Task.WaitAll(Task[], TimeSpan)

Prise en charge par le compilateur du transfert de type lors du multiciblage de mscorlib

Détails

Une nouvelle fonctionnalité CodeDOM permet à un compilateur d’effectuer une compilation sur la version ciblée de mscorlib.dll au lieu de la version .NET Framework 4.5 de mscorlib.dll.

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

Non détectable via l’analyse des API.

ConcurrentQueue<T>.TryPeek peut retourner une valeur Null erronée via son paramètre de sortie

Détails

Dans certains scénarios multithreads, System.Collections.Concurrent.ConcurrentQueue<T>.TryPeek(T) peut retourner la valeur true, mais renseigner le paramètre de sortie avec la valeur Null (au lieu de la valeur correcte).

Suggestion

Ce problème a été résolu dans le .NET Framework 4.5.1. Pour résoudre votre problème, effectuez une mise niveau vers le .NET Framework 4.5.1.

Nom	Valeur
Étendue	Majeure
Version	4,5
Type	Runtime

API affectées

• ConcurrentQueue<T>.TryPeek(T)

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

• EventListener.EnableEvents(EventSource, EventLevel)

Les exceptions qui sont levées pendant un traitement non pris en charge dans System.Threading.Tasks.Task ne se propagent plus sur le thread finaliseur

Détails

Comme la classe System.Threading.Tasks.Task représente une opération asynchrone, elle intercepte toutes les exceptions sans gravité qui se produisent pendant le traitement asynchrone. Dans le .NET Framework 4.5, si une exception n’est pas prise en charge et si votre code n’attend jamais la tâche, l’exception ne se propagera plus sur le thread finaliseur et arrêtera le processus pendant l’opération garbage collection. Cette modification améliore la fiabilité des applications qui utilisent la classe Task pour exécuter un traitement asynchrone non pris en charge.

Suggestion

Si une application dépend d’exceptions asynchrones non prises en charge qui se propagent au thread finaliseur, le comportement précédent peut être restauré en fournissant un gestionnaire approprié pour l’événement UnobservedTaskException ou en définissant un élément de configuration du runtime.

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

• Task.Run(Action)
• Task.Run(Action, CancellationToken)
• Task.Run(Func<Task>)
• Task.Run(Func<Task>, CancellationToken)
• Task.Run<TResult>(Func<TResult>)
• Task.Run<TResult>(Func<TResult>, CancellationToken)
• Task.Run<TResult>(Func<Task<TResult>>)
• Task.Run<TResult>(Func<Task<TResult>>, CancellationToken)
• Task.Start()
• Task.Start(TaskScheduler)

Algorithme List.Sort modifié

Détails

À compter de .NET Framework 4.5, l’algorithme de tri de System.Collections.Generic.List<T> a changé (pour correspondre à un tri approfondi au lieu d’un tri rapide). Le tri de System.Collections.Generic.List<T> n’a jamais été stable, mais cette modification peut aboutir à des tris instables dans le cadre de différents scénarios. Cela signifie simplement que des éléments équivalents peuvent être triés dans des ordres différents lors des appels suivants de l’API.

Suggestion

Comme l’ancien algorithme de tri était également instable (de manière légèrement différente, toutefois), aucun code ne doit dépendre du tri dans un ordre particulier des éléments équivalents. Si des instances de code présentent cette dépendance et réussissent avec l’ancien comportement, ce code doit être mis à jour pour utiliser un comparateur qui va trier de façon déterministe les éléments dans l’ordre souhaité.

Nom	Valeur
Étendue	Mode transparent
Version	4,5
Type	Runtime

API affectées

• List<T>.Sort()
• List<T>.Sort(IComparer<T>)
• List<T>.Sort(Comparison<T>)
• List<T>.Sort(Int32, Int32, IComparer<T>)

Un moniker de framework cible manquant a pour effet de restaurer le comportement de la version 4.0

Détails

Les applications dans lesquelles un System.Runtime.Versioning.TargetFrameworkAttribute n’est pas appliqué au niveau de l’assembly sont automatiquement exécutées à l’aide de la sémantique (Quirks) de .NET Framework 4.0. Pour garantir une haute qualité, il est recommandé d’attribuer explicitement à tous les fichiers binaires un System.Runtime.Versioning.TargetFrameworkAttribute indiquant la version du .NET Framework avec laquelle ils ont été créés. Si vous utilisez un moniker de framework cible dans un fichier projet, MSBuild applique automatiquement un System.Runtime.Versioning.TargetFrameworkAttribute.

Suggestion

Un System.Runtime.Versioning.TargetFrameworkAttribute doit être fourni, soit en ajoutant directement l’attribut à l’assembly, soit en spécifiant une version cible de .Net Framework dans le fichier projet ou par le biais de l’interface graphique utilisateur des propriétés du projet de Visual Studio.

Nom	Valeur
Étendue	Majeure
Version	4,5
Type	Runtime

API affectées

Non détectable via l’analyse des API.

Certaines API .NET provoquent des exceptions EntryPointNotFoundExceptions de première chance (gérées)

Détails

Dans .NET Framework 4.5, un petit nombre de méthodes .NET levaient des exceptions System.EntryPointNotFoundException de première chance. Ces exceptions étaient gérées dans le .NET Framework, mais pouvaient arrêter l’automatisation des tests, car celle-ci ne s’attendait pas à des exceptions de première chance. Ces mêmes API provoquent l’arrêt de certaines exécutions ApiVerifier lorsque HighVersionLie est activé.

Suggestion

Vous pouvez éviter ce problème en effectuant une mise à niveau vers .NET Framework 4.5.1. Vous pouvez aussi mettre à jour le code d’automatisation des tests pour que son exécution ne soit pas arrêtée en cas d’exceptions System.EntryPointNotFoundException de première chance.

	Valeur
Portée	Edge
Version	4,5
Type	Runtime

API affectées

• Debug.Assert(Boolean)
• Debug.Assert(Boolean, String)
• Debug.Assert(Boolean, String, String)
• Debug.Assert(Boolean, String, String, Object[])
• XmlSerializer(Type)

System.Threading.Tasks.Task ne lève plus d’exception ObjectDisposedException après la suppression de l’objet

Détails

À l’exception de IAsyncResult.AsyncWaitHandle, les méthodes System.Threading.Tasks.Task ne lèvent plus d’exception System.ObjectDisposedException après la suppression de l’objet. Cette modification prend en charge l’utilisation des tâches mises en cache. Par exemple, une méthode peut retourner une tâche mise en cache pour représenter une opération déjà terminée au lieu d'allouer une nouvelle tâche. Cette opération était impossible dans les versions précédentes du .NET Framework, car tout consommateur de la tâche pouvait la supprimer, ce qui la rendait inutilisable.

Suggestion

N’oubliez pas que les méthodes Task peuvent ne plus lever d’exceptions System.ObjectDisposedException quand l’objet est supprimé. Si une application dépendait de cette exception pour savoir qu’une tâche avait été supprimée, elle doit être mise à jour pour vérifier explicitement l’état de la tâche à l’aide de Status.

Nom	Valeur
Étendue	Secondaire
Version	4,5
Type	Runtime

API affectées

Non détectable via l’analyse des API.

L’échappement de System.Uri prend maintenant en charge la norme RFC 3986

Détails

L’échappement d’URI a été modifié dans NET Framework 4.5 de manière à prendre en charge la norme RFC 3986. Ces modifications sont les suivantes :

• System.Uri.EscapeDataString(String) représente une séquence d'échappement pour les caractères réservés basés sur la norme RFC 3986.
• System.Uri.EscapeUriString(String) ne représente pas une séquence d'échappement pour les caractères réservés.
• System.Uri.UnescapeDataString(String) ne lève pas d'exception s'il rencontre une séquence d'échappement non valide.
• Les caractères d'échappement non réservés sont sans séquence d'échappement.

Suggestion

• Mettez à jour les applications pour qu’elles ne comptent pas sur System.Uri.UnescapeDataString(String) pour lever une exception en cas de séquence d’échappement non valide. Ces séquences sont à présent directement détectées.
• Il est également possible que les URI avec et sans séquence d’échappement, ainsi que les chaînes de données, varient entre les versions 4.0 et 4.5 du .NET Framework. De plus, ils ne doivent pas être comparés directement entre différentes versions de .NET. Ils doivent être analysés et normalisés dans une seule version du .NET avant de faire l’objet d’une comparaison.

Nom	Valeur
Étendue	Secondaire
Version	4,5
Type	Runtime

API affectées

• Uri.EscapeDataString(String)
• Uri.EscapeUriString(String)
• Uri.UnescapeDataString(String)

Données

Les données Sql_variant utilisent le classement sql_variant plutôt que le classement de la base de données

Détails

Les données sql_variant utilisent le classement sql_variant plutôt que le classement de la base de données.

Suggestion

Cette modification permet de répondre à une éventuelle altération de données si le classement de la base de données est différent du classement sql_variant. Les applications qui s'appuient sur les données endommagées peuvent éventuellement échouer.

Nom	Valeur
Étendue	Mode transparent
Version	4,5
Type	Runtime

API affectées

Non détectable via l’analyse des API.

SqlBulkCopy utilise l’encodage de la colonne de destination pour les chaînes

Détails

Lors de l'insertion de données dans une colonne, System.Data.SqlClient.SqlBulkCopy utilise l'encodage de la colonne de destination plutôt que l'encodage par défaut pour les types VARCHAR et CHAR. Cette modification élimine la possibilité d'altération de données provoquée par l'utilisation de l'encodage par défaut lorsque la colonne de destination n'utilise pas l'encodage par défaut. Dans de rares cas, une application existante peut lever une exception SqlException si la modification de l’encodage produit des données qui sont trop volumineuses pour s’insérer dans la colonne de destination.

Suggestion

Attendez-vous à ce que System.Data.SqlClient.SqlBulkCopy n’endommage plus les données en raison des différences d’encodage. Si des chaînes près de la limite de taille de la colonne de destination sont copiées, il peut être nécessaire d’encoder au préalable les données (à copier pour vérifier que les données contiennent dans la colonne de destination) ou d’intercepter les System.Data.SqlClient.SqlException.

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

• System.Data.SqlClient.SqlBulkCopy
• SqlBulkCopy(SqlConnection)

SqlConnection ne peut plus se connecter à SQL Server 1997 ou des bases de données à l’aide de l’adaptateur VIA

Détails

Les connexions aux bases de données SQL Server à l’aide du protocole VIA (Virtual Interface Adapter) ne sont plus prises en charge. Le protocole utilisé pour se connecter à une base de données SQL Server est visible dans la chaîne de connexion. Une connexion VIA contiendra via:<nom_serveur>. Si cette application se connecte à SQL via un protocole autre que le protocole VIA (tcp: ou np:, par exemple), aucune modification avec rupture n’est détectée. En outre, les connexions à SQL Server 7 (1997) ne sont plus prises en charge.

Suggestion

Comme le protocole VIA est déprécié, un autre protocole doit être utilisé pour se connecter aux bases de données SQL. Le protocole utilisé le plus courant est TCP/IP. Pour plus d’informations sur la connexion TCP/IP, voir Activer le protocole TCP/IP pour une instance de base de données. Si la base de données est accessible uniquement à partir d’un intranet, le protocole des canaux nommés peut offrir de meilleures performances en cas de réseau lent.

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

• SqlConnection(String)
• SqlConnection(String, SqlCredential)

SqlConnection.Open échoue sur Windows 7 si des fournisseurs Winsock BSP ou LSP non-IFS sont installés

Détails

Open() et OpenAsync(CancellationToken) échouent dans .NET Framework 4.5 lors de l’exécution sur un ordinateur Windows 7 si des fournisseurs Winsock BSP ou LSP non-IFS sont installés. Pour déterminer si un fournisseur BSP ou LSP non-IFS est installé, utilisez la commande netsh WinSock Show Catalog et examinez chaque élément Winsock Catalog Provider Entry retourné. Si la valeur des indicateurs de service est définie sur 0x20000, le fournisseur utilise des gestionnaires IFS ce qui lui permet de fonctionner correctement. Si la valeur 0x20000 n’est pas définie, c’est qu’il s’agit d’un BSP ou d’un LSP non IFS.

Suggestion

Ce bogue a été résolu dans le .NET Framework 4.5.2. Vous pouvez donc l’éviter en mettant à niveau votre version du .NET Framework. Vous pouvez également l’éviter en supprimant tous les LSP Winsock non IFS qui sont installés.

Nom	Valeur
Étendue	Secondaire
Version	4,5
Type	Runtime

API affectées

• SqlConnection.Open()
• SqlConnection.OpenAsync(CancellationToken)

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.

Entity Framework

Changement de comportement des API DDL (Data Definition Language)

Détails

Le comportement des API DDL lors de la spécification d’AttachDBFilename a été modifié de la manière suivante :

• Les chaînes de connexion n’ont pas besoin de spécifier de valeur Initial Catalog. Avant, AttachDBFilename et Initial Catalog étaient obligatoires.
• Si AttachDBFilename et Initial Catalog sont spécifiés et que le fichier MDF donné existe, la méthode DatabaseExists retourne true. Auparavant, elle retournait false.
• Si AttachDBFilename et Initial Catalog sont spécifiés et que le fichier MDF donné existe, l’appel de la méthode DeleteDatabase a pour effet de supprimer les fichiers.
• Si la méthode DeleteDatabase est appelée quand la chaîne de connexion spécifie une valeur AttachDBFilename avec un MDF et un catalogue initial qui n’existent pas, la méthode lève une exception InvalidOperationException. Auparavant, elle levait une exception SqlException.

Suggestion

Ces modifications facilitent la création d'outils et d'applications qui utilisent les API DDL. Elles peuvent avoir une incidence sur la compatibilité des applications dans les scénarios suivants :

• L'utilisateur rédige du code qui exécute une commande DROP DATABASE directement au lieu d'appeler DeleteDatabase si DatabaseExists retourne true. Ce comportement altère le code existant si la base de données n'est pas liée mais que le fichier MDF existe.
• L’utilisateur rédige du code qui attend de la méthode DeleteDatabase qu’elle lève une exception SqlException plutôt qu’une exception InvalidOperationException quand le catalogue initial et le fichier MDF n’existent pas.

Nom	Valeur
Étendue	Secondaire
Version	4,5
Type	Runtime

API affectées

Non détectable via l’analyse des API.

Gestion des exceptions différente pour les méthodes ObjectContext.CreateDatabase et DbProviderServices.CreateDatabase

Détails

À compter de .NET Framework 4.5, en cas d’échec de la création d’une base de données, les méthodes CreateDatabase tentent de supprimer la base de données vide. Si cette opération réussit, l’exception System.Data.SqlClient.SqlException d’origine est propagée (au lieu de l’exception System.InvalidOperationException qui était systématiquement levée dans .NET Framework 4.0).

Suggestion

Quand vous interceptez une System.InvalidOperationException en exécutant CreateDatabase() ou CreateDatabase(DbConnection, Nullable<Int32>, StoreItemCollection), SQLExceptions doit maintenant également être interceptée.

Nom	Valeur
Étendue	Secondaire
Version	4,5
Type	Runtime

API affectées

• ObjectContext.CreateDatabase()
• DbProviderServices.CreateDatabase(DbConnection, Nullable<Int32>, StoreItemCollection)

Le chargement d’Entity Framework 6.0 est très lent dans les applications lancées à partir de Visual Studio

Détails

Dans Visual Studio 2013, le lancement d’une application qui utilise Entity Framework 6.0 peut être très long.

Suggestion

Ce problème a été résolu dans EntityFramework 6.0.2. Mettez à jour Entity Framework pour éviter des problèmes de performances.

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

Non détectable via l’analyse des API.

Le nom du fichier journal créé par la méthode ObjectContext.CreateDatabase a été changé pour répondre aux spécifications SQL Server

Détails

Quand la méthode System.Data.Objects.ObjectContext.CreateDatabase() est appelée directement ou en utilisant Code First avec le fournisseur SqlClient et une valeur AttachDBFilename dans la chaîne de connexion, elle crée un fichier journal nommé nom_fichier_log.ldf au lieu de nom_fichier.ldf (où « nom_fichier » correspond au nom du fichier spécifié par la valeur AttachDBFilename). Cette modification améliore le débogage en fournissant un fichier journal dont le nom répond aux spécifications SQL Server.

Suggestion

Si le nom du fichier journal est important pour une application, celle-ci doit être mise à jour pour attendre le format de nom de fichier standard « _log.ldf ».

	Valeur
Portée	Edge
Version	4,5
Type	Runtime

API affectées

• ObjectContext.CreateDatabase()

ObjectContext.Translate et ObjectContext.ExecuteStoreQuery prennent maintenant en charge le type enum

Détails

Dans .NET Framework 4.0, le paramètre générique T des méthodes ObjectContext.Translate et ObjectContext.ExecuteStoreQuery ne pouvait pas être une énumération. Ce scénario est désormais pris en charge.

Suggestion

Si Translate ou ExecuteStoreQuery était appelé sur un type enum dans .NET Framework 4.0, la valeur « 0 » était retournée. Si ce comportement était celui souhaité, les appels devaient être remplacés par une constante 0 (ou l’équivalent enum de celle-ci).

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

• ObjectContext.Translate<TElement>(DbDataReader)
• ObjectContext.Translate<TEntity>(DbDataReader, String, MergeOption)
• ObjectContext.ExecuteStoreQuery<TElement>(String, Object[])
• ObjectContext.ExecuteStoreQuery<TEntity>(String, String, MergeOption, Object[])

LINQ

Enumerable.Empty<TResult> retourne toujours une instance mise en cache

Détails

À compter de .NET Framework 4.5, Empty<TResult>() retourne toujours une instance interne mise en cache IEnumerable<T>. Avant, Empty<TResult>() mettait en cache un IEnumerable<T> vide lors de l’appel de l’API, ce qui signifiait que dans certaines conditions, quand Empty<TResult>() était appelé rapidement et simultanément, différentes instances du type pouvaient être retournées pour différents appels à l’API.

Suggestion

Étant donné que l’ancien comportement était non déterministe, il est peu probable que le code en dépende. Toutefois, dans le cas peu probable où des énumérables vides sont comparés et supposés être parfois inégaux, vous devez créer des tableaux vides explicites (new T[0]) au lieu d’utiliser Empty<TResult>().

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

• Enumerable.Empty<TResult>()

Managed Extensibility Framework (MEF)

Les catalogues MEF implémentent IEnumerable et ne peuvent donc plus être utilisés pour créer un sérialiseur

Détails

À compter de .NET Framework 4.5, les catalogues MEF implémentent IEnumerable et ne peuvent donc plus être utilisés pour créer un sérialiseur (objet System.Xml.Serialization.XmlSerializer). La tentative de sérialisation d'un catalogue MEF lève une exception.

Suggestion

Ne peut plus utiliser un catalogue MEF pour créer un sérialiseur

Nom	Valeur
Étendue	Majeure
Version	4,5
Type	Runtime

API affectées

Non détectable via l’analyse des API.

Mise en réseau

La désérialisation des objets MailMessage sérialisés sous .NET Framework 4.5 peut échouer

Détails

À compter de .NET Framework 4.5, les objets MailMessage peuvent inclure des caractères non-ASCII. Dans le .NET Framework 4, seuls les caractères ASCII sont pris en charge. Les objets MailMessage qui contiennent des caractères non-ASCII et qui sont sérialisés sous .NET Framework 4.5 ou ultérieur ne peuvent pas être désérialisés dans .NET Framework 4.

Suggestion

Vérifiez que votre code assure la gestion des exceptions lors de la désérialisation d’un objet MailMessage.

Nom	Valeur
Étendue	Secondaire
Version	4,5
Type	Runtime

API affectées

• System.Web.Mail.MailMessage

System.Net.PeerToPeer.Collaboration n’est pas disponible sur Windows 8

Détails

L’espace de noms System.Net.PeerToPeer.Collaboration est indisponible sur Windows 8 et versions ultérieures.

Suggestion

Les applications qui prennent en charge Windows 8 et ultérieur doivent être modifiées de manière à ne pas dépendre de cet espace de noms ou de ses membres.

Nom	Valeur
Étendue	Majeure
Version	4,5
Type	Runtime

API affectées

• System.Net.PeerToPeer.Collaboration

Impression

Les données écrites dans PrintSystemJobInfo.JobStream doivent être au format XPS

Détails

La propriété JobStream expose le flux d’un travail d’impression. L’utilisateur peut envoyer des données brutes aux composants d’impression du système d’exploitation sous-jacent en écrivant dans ce flux. À compter de .NET Framework 4.5 sur Windows 8 et les versions ultérieures du système d’exploitation Windows, les données écrites dans ce flux doivent être au format XPS en tant que flux de package.

Suggestion

Pour sortir le contenu d’impression, vous pouvez procéder de l’une des manières suivantes :

• Utilisez la classe XpsDocumentWriter pour sortir le contenu d’impression. Il s’agit de l’alternative recommandée.
• Vérifiez que les données envoyées au flux retourné par la propriété JobStream sont au format XPS en tant que flux de package.

Nom	Valeur
Étendue	Secondaire
Version	4,5
Type	Runtime

API affectées

• PrintSystemJobInfo.JobStream

Sérialisation

BinaryFormatter peut ne pas parvenir à trouver le type dans le contexte LoadFrom

Détails

Depuis .NET Framework 4.5, un certain nombre de modifications de System.Xml.Serialization.XmlSerializer peuvent entraîner des différences de désérialisation quand vous utilisez System.Runtime.Serialization.Formatters.Binary.BinaryFormatter pour désérialiser des types qui avaient été chargés dans le contexte LoadFrom. Ces modifications sont dues aux nouvelles façons dont System.Xml.Serialization.XmlSerializer charge maintenant un type qui provoque un comportement différent quand un System.Runtime.Serialization.Formatters.Binary.BinaryFormatter tente plus tard une désérialisation en ce type. Le binder de sérialisation par défaut n’effectue pas automatiquement des recherches dans le contexte LoadFrom, bien qu’il ait pu fonctionner dans certains cas en fonction de l’ancien comportement de XmlSerializer. En raison des modifications, quand un type est chargé à partir d’un assembly chargé dans un contexte différent, une System.IO.FileNotFoundException peut être levée.

Avertissement

La sérialisation binaire avec BinaryFormatter peut être dangereuse. Pour plus d’informations, consultez le Guide de sécurité BinaryFormatter.

Suggestion

Si cette exception se produit, la propriété Binder de System.Runtime.Serialization.Formatters.Binary.BinaryFormatter peut être définie sur un binder personnalisé qui va rechercher le type approprié.

var formatter = new BinaryFormatter { Binder = new TypeFinderBinder() }

Puis le binder personnalisé :

public class TypeFinderBinder : SerializationBinder
{
    private static readonly string s_assemblyName = Assembly.GetExecutingAssembly().FullName;

    public override Type BindToType(string assemblyName, string typeName)
    {
        return Type.GetType(String.Format(CultureInfo.InvariantCulture, "{0}, {1}", typeName, s_assemblyName));
    }
}

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

• System.Runtime.Serialization.Formatters.Binary.BinaryFormatter
• BinaryFormatter.Deserialize(Stream)
• BinaryFormatter.Deserialize(Stream, HeaderHandler)

SoapFormatter ne peut pas désérialiser Hashtable et les objets de collection ordonnée similaires

Détails

System.Runtime.Serialization.Formatters.Soap.SoapFormatter ne garantit pas que les objets sérialisés dans une version du .NET Framework pourront être désérialisés correctement dans une autre version. En effet, certaines collections ordonnées (comme System.Collections.Hashtable) ont gagné de nouveaux membres entre les versions 4.0 et 4.5. De fait, les objets de ces types ne peuvent pas être désérialisés avec .NET Framework 4.0 s’ils ont été sérialisés avec .NET Framework 4.5. Notez que si les données sérialisées sont sérialisées et désérialisées avec la même version du .NET Framework, aucun problème ne se produit.

Suggestion

La sérialisation System.Runtime.Serialization.Formatters.Soap.SoapFormatter doit être remplacée par la sérialisation System.Runtime.Serialization.Formatters.Binary.BinaryFormatter ou System.Runtime.Serialization.NetDataContractSerializer pour ne pas être affectée par les changements du .NET Framework.

Avertissement

La sérialisation binaire avec BinaryFormatter peut être dangereuse. Pour plus d’informations, consultez le Guide de sécurité BinaryFormatter.

Nom	Valeur
Étendue	Secondaire
Version	4,5
Type	Runtime

API affectées

• SoapFormatter.Serialize(Stream, Object)
• SoapFormatter.Serialize(Stream, Object, Header[])
• SoapFormatter.Deserialize(Stream)
• SoapFormatter.Deserialize(Stream, HeaderHandler)

XmlSerializer échoue lors de la sérialisation d’un type qui masque un membre accessible avec un membre inaccessible

Détails

Lors de la sérialisation d’un type dérivé, System.Xml.Serialization.XmlSerializer peut échouer si le type contient un champ ou une propriété inaccessible qui masque (via le mot clé 'new') un champ ou une propriété portant le même nom précédemment accessible (public, par exemple) sur le type de base.

Suggestion

Ce problème peut être résolu en rendant le nouveau membre masqué accessible au System.Xml.Serialization.XmlSerializer (en le marquant public, par exemple). Sinon, le paramètre de configuration suivant rétablit le comportement 4.0 de System.Xml.Serialization.XmlSerializer, ce qui résout le problème :

<system.xml.serialization>
<xmlSerializer useLegacySerializerGeneration="true" />
</system.xml.serialization>

Nom	Valeur
Étendue	Secondaire
Version	4,5
Type	Runtime

API affectées

• XmlSerializer.Serialize(Stream, Object)
• XmlSerializer.Serialize(TextWriter, Object)
• XmlSerializer.Serialize(Object, XmlSerializationWriter)
• XmlSerializer.Serialize(XmlWriter, Object)
• XmlSerializer.Serialize(Stream, Object, XmlSerializerNamespaces)
• XmlSerializer.Serialize(TextWriter, Object, XmlSerializerNamespaces)
• XmlSerializer.Serialize(XmlWriter, Object, XmlSerializerNamespaces)
• XmlSerializer.Serialize(XmlWriter, Object, XmlSerializerNamespaces, String)
• XmlSerializer.Serialize(XmlWriter, Object, XmlSerializerNamespaces, String, String)

Applications web

Les navigateurs managés hébergeant des contrôles de .NET Framework 1.1 et 2.0 sont bloqués

Détails

L'hébergement de ces contrôles est bloqué dans Internet Explorer.

Suggestion

Internet Explorer ne démarrera pas les applications qui utilisent des contrôles d'hébergement de navigateur géré. Le comportement précédent peut être restauré en définissant la valeur de EnableIEHosting de la sous-clé de Registre HKLM/SOFTWARE/MICROSOFT/.NETFramework sur 1 pour les systèmes x86 et pour les processus 32 bits sur les systèmes x64, et définissant la valeur EnableIEHosting de la sous-clé de Registre HKLM/SOFTWARE/Wow6432Node/Microsoft/.NETFramework sur 1 pour les processus 64 bits sur les systèmes x64.

Nom	Valeur
Étendue	Secondaire
Version	4,5
Type	Runtime

API affectées

Non détectable via l’analyse des API.

Windows Communication Foundation (WCF)

Les codes d’erreur pour maxRequestLength ou maxReceivedMessageSize sont différents

Détails

Les messages dans les services web WCF hébergés dans les services IIS (Internet Information Services) ou sur le serveur de développement ASP.NET qui dépassent maxRequestLength (dans ASP.NET) ou maxReceivedMessageSize (dans WCF) ont un code d’erreur différent. Le code d’état HTTP est passé de 400 (Demande incorrecte) à 413 (Entité de demande trop grande), et les messages qui dépassent le paramètre maxRequestLength ou maxReceivedMessageSize lèvent une exception System.ServiceModel.ProtocolException. Cela inclut les cas dans lesquels le mode de transfert est Transmis en continu.

Suggestion

Cette modification facilite le débogage dans les cas où la longueur du message dépasse les limites autorisées par ASP.NET ou WCF. Vous devez modifier tout code qui effectue un traitement en fonction d’un code d’état HTTP 400.

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

Non détectable via l’analyse des API.

L’objet System.ServiceModel.Web.WebServiceHost n’ajoute plus de point de terminaison par défaut

Détails

L’objet WebServiceHost n’ajoute plus de point de terminaison par défaut si un point de terminaison explicite a été ajouté par le code de l’application.

Suggestion

Si les utilisateurs s’attendent à pouvoir se connecter à un point de terminaison par défaut alors que d’autres points de terminaison explicites ont été ajoutés à System.ServiceModel.Web.WebServiceHost, les points de terminaison par défaut doivent également être ajoutés explicitement (à l’aide d’System.ServiceModel.ServiceHostBase.AddDefaultEndpoints()).

Nom	Valeur
Étendue	Secondaire
Version	4,5
Type	Runtime

API affectées

• ServiceHost.AddServiceEndpoint(Type, Binding, String)
• ServiceHost.AddServiceEndpoint(Type, Binding, Uri)
• ServiceHost.AddServiceEndpoint(Type, Binding, String, Uri)
• ServiceHost.AddServiceEndpoint(Type, Binding, Uri, Uri)
• ServiceHost.AddServiceEndpoint(Type, Binding, Uri, Uri)
• ServiceHostBase.AddServiceEndpoint(ServiceEndpoint)
• ServiceHostBase.AddServiceEndpoint(String, Binding, String)
• ServiceHostBase.AddServiceEndpoint(String, Binding, Uri)
• ServiceHostBase.AddServiceEndpoint(String, Binding, String, Uri)
• ServiceHostBase.AddServiceEndpoint(String, Binding, Uri, Uri)

La méthode Replace est désactivée par défaut dans les URL OData

Détails

À compter de la version 4.5 du .NET Framework, la méthode Replace des URL OData est désactivée par défaut. Quand la méthode Replace OData est désactivée (ce qui est désormais le cas par défaut), toutes les demandes utilisateur, y compris les fonctions de remplacement (qui sont rares) échouent.

Suggestion

Si la méthode Replace est nécessaire (ce qui est rare), elle peut être réactivée via les paramètres de configuration (System.Data.Services.Configuration.DataServicesFeaturesSection.ReplaceFunction). Toutefois, l’activation d’une méthode Replace peut créer des failles de sécurité et ne doit donc être utilisée qu’après un examen minutieux.

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

• System.Data.Services.DataService<T>

Windows Forms

PreviewLostKeyboardFocus est appelé de façon répétée si son gestionnaire affiche une boîte de message Windows Forms

Détails

À compter de la version 4.5 du .NET Framework, quand vous appelez MessageBox.Show à partir d’un gestionnaire PreviewLostKeyboardFocus, le gestionnaire est redéclenché quand la boîte de message est fermée, ce qui peut aboutir à une boucle infinie de boîtes de message.

Suggestion

Il existe deux options pour contourner ce problème :

• Vous pouvez appeler MessageBox.Show au lieu de MessageBox.Show.
• Vous pouvez afficher la boîte de message à partir d’un gestionnaire d’événements LostKeyboardFocus (au lieu du gestionnaire d’événements System.Windows.UIElement.PreviewLostKeyboardFocus).

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

• ContentElement.PreviewLostKeyboardFocus
• IInputElement.PreviewLostKeyboardFocus
• UIElement.PreviewLostKeyboardFocus
• UIElement3D.PreviewLostKeyboardFocus

La propriété CheckForOverflowUnderflow de WinForm est désormais true pour System.Drawing

Détails

La propriété CheckForOverflowUnderflow pour l’assembly System.Drawing.dll est définie sur true.

Suggestion

Auparavant, en cas de dépassement de capacité, le résultat était tronqué automatiquement. Désormais, une exception System.OverflowException est levée.

Nom	Valeur
Étendue	Edge
Version	4,5
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

• DataGrid.UnloadingRow
• DataGrid.UnloadingRowDetails

L’appel de DataGrid.CommitEdit à partir d’un gestionnaire CellEditEnding supprime le focus

Détails

L’appel de CommitEdit() depuis un des gestionnaires d’événements System.Windows.Controls.DataGrid.CellEditEnding de System.Windows.Controls.DataGrid fait que System.Windows.Controls.DataGrid perd le focus.

Suggestion

Ce bogue a été résolu dans le .NET Framework 4.5.2. Vous pouvez donc l’éviter en mettant à niveau votre version du .NET Framework. Vous pouvez également contourner ce problème en resélectionnant explicitement System.Windows.Controls.DataGrid après avoir appelé System.Windows.Controls.DataGrid.CommitEdit().

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

• DataGrid.CommitEdit()
• DataGrid.CommitEdit(DataGridEditingUnit, Boolean)

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

• CollectionView.Refresh()

FlowDocument peut afficher une ligne de texte supplémentaire

Détails

Dans certains cas, un élément FlowDocument affiche une ligne de texte supplémentaire lors de l’exécution sur .NET Framework 4.5 par rapport à la façon dont il s’affichait lors de l’exécution sur .NET Framework 4.0. Il n’existe aucun cas connu où ce changement provoquerait un affichage incorrect ou illisible du texte, mais il peut avoir comme conséquence que du texte qui était omis dans la vue de FlowDocument désormais apparaisse.

Suggestion

Dans certains cas, la diminution d’une unité de la valeur de la propriété PageHeight pour l’élément d’un affichage peut rétablir le nombre précédent de lignes affichées.

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

• FlowDocument()
• FlowDocument(Block)
• FlowDocumentReader()
• FlowDocumentPageViewer()
• DocumentPageView()

GlyphRun.ComputeInkBoundingBox() et FormattedText.Extent retournent des valeurs différentes à compter de .NET Framework 4.5

Détails

Des améliorations ont été apportées à ComputeInkBoundingBox() et à Extent dans .NET Framework 4.5 pour résoudre les problèmes où la taille des rectangles pour les glyphes qu’ils contenaient était parfois trop petite dans .NET Framework 4.0. Dans le .NET Framework 4.5, certains rectangles englobants sont désormais plus grands, ce qui entraîne des différences subtiles dans la disposition de l’interface utilisateur.

Suggestion

Notez que la taille de certains rectangles englobants de glyphes a été augmentée. Ces modifications sont censées améliorer la présentation et les tests hitbox. Toutefois, si vous souhaitez utiliser l’ancien comportement (versions antérieures au .NET 4.5), ajoutez l’entrée suivante au fichier app.config :

<appsettings>
<add key="IncludeAllInkInBoundingBox" value="false">
</appsettings>

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

• GlyphRun.ComputeInkBoundingBox()
• FormattedText.Extent

Impossibilité intermittente de faire défiler jusqu’à l’élément du bas dans les ItemsControls (comme ListBox et DataGrid) lors de l’utilisation de DataTemplates personnalisés

Détails

Dans certains cas, un bogue du .NET Framework 4.5 empêche le défilement des ItemsControls (comme System.Windows.Controls.ListBox, System.Windows.Controls.ComboBox, System.Windows.Controls.DataGrid, etc.) jusqu’au dernier élément quand vous utilisez des DataTemplates personnalisés. Si le défilement est tenté une deuxième fois (après avoir fait défiler jusqu’en haut), il fonctionnera.

Suggestion

Étant donné que ce problème a été résolu dans le .NET Framework 4.5.2, vous pouvez également mettre à niveau votre version du .NET Framework. Vous pouvez également faire glisser les barres de défilement jusqu’au dernier élément de la collection, mais aurez peut-être à recommencer l’opération une deuxième fois pour y arriver.

Nom	Valeur
Étendue	Secondaire
Version	4,5
Type	Runtime

API affectées

Non détectable via l’analyse des API.

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

• MultiSelector.SelectedItems

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

• ObservableCollection<T>.Move(Int32, Int32)
• ObservableCollection<T>.MoveItem(Int32, Int32)

Nouvelles valeurs enum dans le PageRangeSelection de WPF

Détails

Deux nouveaux membres (System.Windows.Controls.PageRangeSelection.CurrentPage et System.Windows.Controls.PageRangeSelection.SelectedPages) ont été ajoutés à l’énumération System.Windows.Controls.PageRangeSelection.

Suggestion

Dans la plupart des cas, ces modifications n’affectent pas le code utilisateur. Le code qui dépend d’un certain nombre d’éléments existants dans les appels de GetNames(Type) et de GetValues(Type) sur le type System.Windows.Controls.PageRangeSelection doit cependant être modifié.

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

• System.Windows.Controls.PageRangeSelection

PreviewLostKeyboardFocus est appelé de façon répétée si son gestionnaire affiche une boîte de message Windows Forms

Détails

À compter de la version 4.5 du .NET Framework, quand vous appelez MessageBox.Show à partir d’un gestionnaire PreviewLostKeyboardFocus, le gestionnaire est redéclenché quand la boîte de message est fermée, ce qui peut aboutir à une boucle infinie de boîtes de message.

Suggestion

Il existe deux options pour contourner ce problème :

• Vous pouvez appeler MessageBox.Show au lieu de MessageBox.Show.
• Vous pouvez afficher la boîte de message à partir d’un gestionnaire d’événements LostKeyboardFocus (au lieu du gestionnaire d’événements System.Windows.UIElement.PreviewLostKeyboardFocus).

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

• ContentElement.PreviewLostKeyboardFocus
• IInputElement.PreviewLostKeyboardFocus
• UIElement.PreviewLostKeyboardFocus
• UIElement3D.PreviewLostKeyboardFocus

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

• DataGrid()

Le défilement d’un TreeView WPF ou d’un ListBox groupé dans un VirtualizingStackPanel peut entraîner l’arrêt de la réponse de l’application

Détails

Dans .NET Framework v4.5, le défilement d’un System.Windows.Controls.TreeView WPF dans un panneau de pile virtualisé peut entraîner l’arrêt de la réponse de l’application en cas de marges dans la fenêtre d’affichage (entre les éléments du System.Windows.Controls.TreeView, par exemple, ou sur un élément ItemsPresenter). En outre, dans certains cas, des éléments de taille différente dans une même vue peuvent causer une instabilité, même s’il n’y a pas de marges.

Suggestion

Vous pouvez éviter ce problème en effectuant une mise à niveau vers .NET Framework 4.5.1. Vous pouvez également supprimer les marges des collections de vue (comme les System.Windows.Controls.TreeViews) dans les panneaux d’empilement virtualisés, si tous les éléments qu’ils contiennent sont de même taille.

Nom	Valeur
Étendue	Majeure
Version	4,5
Type	Runtime

API affectées

• VirtualizingStackPanel.SetIsVirtualizing(DependencyObject, Boolean)

Les éléments DataTemplate WPF sont désormais détectés par UI Automation

Détails

Avant, les éléments System.Windows.DataTemplate étaient invisibles pour UI Automation. À compter de la version 4.5, UI Automation détecte ces éléments. C’est pratique dans de nombreux cas, mais peut compromettre les tests qui dépendent des arborescences UI Automation qui ne contiennent pas d’éléments System.Windows.DataTemplate.

Suggestion

Les tests UI Automation pour cette application peuvent nécessiter des modifications pour prendre en compte l’arborescence UI Automation qui contient maintenant des éléments System.Windows.DataTemplate qui étaient invisibles. Par exemple, les tests qui attendent des éléments contigus doivent maintenant s’attendre à ce que des éléments UIA, autrefois indétectables, se trouvent entre ces éléments. Autre exemple : Les tests qui reposent sur certains nombres ou index pour les éléments UIA peuvent nécessiter la modification de leurs valeurs.

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

• DataTemplate()
• DataTemplate(Object)

Le DispatcherSynchronizationContext.CreateCopy WPF retourne désormais une nouvelle copie au lieu de l’instance actuelle

Détails

Dans .NET Framework 4, CreateCopy() retournait une référence à l’instance actuelle, principalement pour optimiser les performances. Dans le .NET Framework 4.5, il retourne une nouvelle instance, ce qui permet, pour la première fois, de conclure que les références égales indiquent que le thread en cours d’exécution se trouve dans le bon contexte de synchronisation. Il est peu probable que le code qui vérifie l’identité de ces références soit affecté. Cependant, en raison de cette modification, le code qui appelle CreateCopy() doit être testé dans le cadre de la migration vers .NET Framework 4.5 ou ultérieur.

Suggestion

N’oubliez pas que CreateCopy() retourne désormais un nouvel objet System.Threading.SynchronizationContext. Avant, le code qui utilisait l’équivalence des références générées de cette manière ne vérifiait pas réellement si le contexte était approprié. À présent, avec .NET Framework 4.5 ou ultérieur, le contexte est bien vérifié. Bien que cela soit peu susceptible de provoquer des problèmes, l’utilisation des chemins de code concernés doit suffire à déterminer si cela peut poser un problème.

Nom	Valeur
Étendue	Secondaire
Version	4,5
Type	Runtime

API affectées

• DispatcherSynchronizationContext.CreateCopy()

Le nombre maximal d’annulations d’opérations pour une zone de texte WPF est de 100 par défaut

Détails

Dans .NET Framework 4.5, le nombre maximal d’annulations d’opérations pour une zone de texte WPF est de 100 par défaut (dans .NET Framework 4.0, ce nombre était illimité).

Suggestion

Si ce nombre n’est pas suffisant, vous pouvez définir explicitement cette valeur avec UndoLimit

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

• System.Windows.Controls.TextBox

Le texte sélectionné dans la zone de texte WPF sélectionnée s’affiche dans une autre couleur quand la zone de texte est inactive

Détails

Dans .NET Framework 4.5, quand un contrôle de zone de texte WPF est inactif (c’est-à-dire qu’il n’a pas le focus), le texte sélectionné dans la zone s’affiche dans une couleur différente de celle utilisée quand le contrôle est actif.

Suggestion

Vous pouvez restaurer le comportement précédent (.NET Framework 4.0) en affectant la valeur false à la propriété AreInactiveSelectionHighlightBrushKeysSupported.

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

• System.Windows.Controls.TextBox

Les éléments TreeViewItem WPF doivent être utilisés dans un contrôle TreeView

Détails

Une modification a été introduite dans 4.5, qui limite l’utilisation des éléments System.Windows.Controls.TreeViewItem en dehors d’un System.Windows.Controls.TreeView. Cette restriction est applicable dans les cas suivants :

• L’objet visuel parent de System.Windows.Controls.TreeViewItem n’est pas un panneau. (Un System.Windows.Controls.TreeViewItem généré pour un System.Windows.Controls.TreeView aura un panneau comme parent)
• Le System.Windows.Controls.TreeViewItem est un descendant d’un System.Windows.Controls.VirtualizingStackPanel agissant comme « hôte des éléments » pour un contrôle de liste (ListBox, DataGrid, ListView, etc.). Il n’est pas nécessaire d’activer la virtualisation.
• Le System.Windows.Controls.VirtualizingStackPanel peut faire défiler les éléments (ScrollUnit="Item").
• VirtualizingStackPanel.MakeVisible(v) est appelé pour faire défiler un élément v dans l’affichage. Vous pouvez faire ceci de manière explicite ou implicite de différentes façons. Le moyen le plus courant est de cliquer sur v pour lui donner le focus clavier.
• La chaîne du parent visuel de v à System.Windows.Controls.VirtualizingStackPanel passe par System.Windows.Controls.TreeViewItem.

En d’autres termes, cela se produit quand un System.Windows.Controls.TreeViewItem est utilisé en dehors d’un System.Windows.Controls.TreeView, et que l’utilisateur clique sur un descendant du System.Windows.Controls.TreeViewItem pour l’afficher. Si le System.Windows.Controls.TreeViewItem n’a pas de descendant pouvant recevoir le focus, vous ne rencontrez jamais ce problème. Cela peut se produire quand un System.Windows.Controls.TreeViewItem est la racine d’un DataTemplate. Une exception InvalidCastException est alors levée dans le cadre de WPF.

Suggestion

Un correctif sera mis à disposition pour résoudre ce problème.

Nom	Valeur
Étendue	Secondaire
Version	4,5
Type	Runtime

API affectées

Non détectable via l’analyse des API.

Windows Workflow Foundation (WF)

System.Activities est maintenant APTCA

Détails

L'assembly est marqué avec l'attribut System.Security.AllowPartiallyTrustedCallersAttribute.

Suggestion

Les classes dérivées ne peuvent pas être marquées avec l'objet System.Security.SecurityCriticalAttribute. Auparavant, les types dérivés devaient être marqués avec l'objet System.Security.SecurityCriticalAttribute. Toutefois, cette modification ne doit pas avoir d'impact réel.

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

Non détectable via l’analyse des API.

WF sérialise désormais différemment les objets DateTimes Expressions.Literal<T> (il arrête les analyseurs XAML personnalisés)

Détails

L’objet ValueSerializer associé convertira un objet System.DateTime ou System.DateTimeOffset dont les composants Second et System.DateTime.Millisecond ne sont pas nuls et (pour une valeur de System.DateTime) dont la propriété Kind n’est pas Unspecified pour la syntaxe d’élément de propriété au lieu d’une chaîne. Cette modification permet aux valeurs System.DateTime et System.DateTimeOffset de faire l'objet d'un aller-retour. Les analyseurs XAML personnalisés qui supposent que l'entrée XAML figure dans la syntaxe d'attribut ne fonctionnent pas correctement.

Suggestion

Cette modification permet aux valeurs System.DateTime et System.DateTimeOffset de faire l'objet d'un aller-retour. Les analyseurs XAML personnalisés qui supposent que l'entrée XAML figure dans la syntaxe d'attribut ne fonctionnent pas correctement.

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

Non détectable via l’analyse des API.

XML, XSLT

XmlSchemaException définit désormais les positions de ligne correctement

Détails

Si la valeur SetLineInfo est passée à la méthode Load et qu’une erreur de validation se produit, les propriétés LineNumber et LinePosition contiennent désormais les informations de ligne.

Suggestion

Le code de gestion des exceptions qui suppose que LineNumber et LinePosition ne seront pas définies doit être modifié, car ces propriétés seront maintenant définies correctement quand SetLineInfo est utilisé lors du chargement du code XML.

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

• LoadOptions.SetLineInfo

L’extension d’entité DTD de XmlTextReader est limitée à 10 000 000 caractères.

Détails

L’extension d’entité DTD est désormais limitée à 10 000 000 caractères. Le chargement des fichiers XML sans extension d'entité DTD ou avec une extension d'entité DTD limitée reste inchangé. Les fichiers avec des entités DTD qui s'étendent à plus de 10 000 000 caractères ne se chargent pas et lèvent désormais une exception.

Suggestion

Si la limite de l’extension d’entité DTD n’est pas suffisante, la valeur peut être remplacée par la propriété MaxCharactersFromEntities. Un System.Xml.XmlReaderSettings avec la valeur System.Xml.XmlReaderSettings.MaxCharactersFromEntities correcte peut être passé à XmlReader.Create qui prend System.Xml.XmlReaderSettings (c’est-à-dire Create(String, XmlReaderSettings))

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

• System.Xml.XmlTextReader
• XmlTextReader()
• XmlTextReader(Stream)
• XmlTextReader(Stream, XmlNameTable)
• XmlTextReader(Stream, XmlNodeType, XmlParserContext)
• XmlTextReader(TextReader)
• XmlTextReader(TextReader, XmlNameTable)
• XmlTextReader(String)
• XmlTextReader(String, Stream)
• XmlTextReader(String, Stream, XmlNameTable)
• XmlTextReader(String, TextReader)
• XmlTextReader(String, TextReader, XmlNameTable)
• XmlTextReader(String, XmlNameTable)
• XmlTextReader(String, XmlNodeType, XmlParserContext)
• XmlTextReader(XmlNameTable)

La compatibilité ascendante de XSLT fonctionne désormais

Détails

Dans .NET Framework 4, la compatibilité ascendante de XSLT 1.0 avait les problèmes suivants :

• Le chargement d'une feuille de style échouait si sa version avait la valeur 2.0 et si l'analyseur rencontrait une construction XSLT 1.0 non reconnue.
• La construction xsl:sort ne pouvait pas trier les données si la version de la feuille de style était définie sur 1.1. Dans le .NET Framework 4.5, ces problèmes ont été résolus et le mode de compatibilité ascendante de XSLT 1.0 fonctionne correctement.

Suggestion

La plupart des applications ne devraient pas être affectées, mais les données sont triées différemment dans certains cas maintenant que xsl:sort est respecté. Si xsl:sort est utilisé dans des feuilles de style 1.1, vérifiez que les applications ne dépendaient pas de l’ordre non trié des données. Si des applications s’appuient sur le comportement de tri de la version 4.0, supprimez xsl:sort de la feuille de style.

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

• System.Xml.Xsl.XslCompiledTransform

Le message de l’exception relative aux feuilles de style XSLT a été changé

Détails

Dans le .NET Framework 4.5, lorsqu’un fichier XSLT est trop complexe, le texte du message d’erreur est le suivant : « La feuille de style est trop complexe. ». Dans les versions antérieures, le message d’erreur était « Erreur de compilation XSLT. ». Le code d’application qui dépend du texte du message d’erreur ne fonctionne plus. Toutefois, comme les types d’exception restent les mêmes, cette modification ne devrait pas avoir d’impact réel.

Suggestion

Mettez à jour le code d’application qui dépend du message d’exception de cette condition d’erreur pour qu’il attende le nouveau message ou (encore mieux) mettez à jour le code pour qu’il dépende uniquement du type d’exception (System.Xml.Xsl.XsltException), qui n’a pas changé.

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

• XslCompiledTransform.Load(String)
• XslCompiledTransform.Load(Type)
• XslCompiledTransform.Load(XmlReader)
• XslCompiledTransform.Load(IXPathNavigable)
• XslCompiledTransform.Load(MethodInfo, Byte[], Type[])
• XslCompiledTransform.Load(String, XsltSettings, XmlResolver)
• XslCompiledTransform.Load(XmlReader, XsltSettings, XmlResolver)
• XslCompiledTransform.Load(IXPathNavigable, XsltSettings, XmlResolver)

.NET Framework 4.5.1

ADO.NET

ADO.NET tente maintenant de reconnecter automatiquement les connexions SQL rompues

Détails

À compter de .NET Framework 4.5.1, le .NET Framework tente de reconnecter automatiquement les connexions SQL rompues. Bien que cette opération améliore généralement la fiabilité des applications, il existe des cas particuliers où une application doit savoir que la connexion a été perdue afin de pouvoir prendre des mesures lors de la reconnexion.

Suggestion

Si cette fonctionnalité n’est pas souhaitable pour des raisons de compatibilité, elle peut être désactivée en affectant à la propriété System.Data.SqlClient.SqlConnectionStringBuilder.ConnectRetryCount d’une chaîne de connexion (ou System.Data.SqlClient.SqlConnectionStringBuilder) la valeur 0.

Nom	Valeur
Étendue	Edge
Version	4.5.1
Type	Runtime

API affectées

• IDbConnection.ConnectionString
• SqlConnection.ConnectionString
• ConnectionStringSettings.ConnectionString
• DbConnection.ConnectionString
• DbConnectionStringBuilder.ConnectionString
• SqlConnectionStringBuilder()
• SqlConnectionStringBuilder(String)
• DbConnectionStringBuilder()
• DbConnectionStringBuilder(Boolean)

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.

ConcurrentQueue<T>.TryPeek peut retourner une valeur Null erronée via son paramètre de sortie

Détails

Dans certains scénarios multithreads, System.Collections.Concurrent.ConcurrentQueue<T>.TryPeek(T) peut retourner la valeur true, mais renseigner le paramètre de sortie avec la valeur Null (au lieu de la valeur correcte).

Suggestion

Ce problème a été résolu dans le .NET Framework 4.5.1. Pour résoudre votre problème, effectuez une mise niveau vers le .NET Framework 4.5.1.

Nom	Valeur
Étendue	Majeure
Version	4,5
Type	Runtime

API affectées

• ConcurrentQueue<T>.TryPeek(T)

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.

La désérialisation d’objets entre les domaines d’application peut échouer

Détails

Dans certains cas, quand une application utilise deux domaines d'application ou plus avec des bases d'application différentes, une tentative de désérialisation des objets dans le contexte d'appel logique entre les domaines d'application lève une exception.

Suggestion

Consultez Atténuation : désérialisation des objets entre les domaines d’application

Nom	Valeur
Étendue	Edge
Version	4.5.1
Type	Runtime

API affectées

Non détectable via l’analyse des API.

EventListener tronque les chaînes comportant des valeurs Null incorporées

Détails

System.Diagnostics.Tracing.EventListener tronque les chaînes comportant des valeurs null incorporées. Les caractères Null ne sont pas pris en charge par la classe System.Diagnostics.Tracing.EventSource. La modification affecte uniquement les applications qui utilisent System.Diagnostics.Tracing.EventListener pour lire des données System.Diagnostics.Tracing.EventSource dans le processus et qui utilisent des caractères Null comme délimiteurs.

Suggestion

Les données System.Diagnostics.Tracing.EventSource doivent être, si possible, mises à jour pour ne pas utiliser les caractères Null incorporés.

Nom	Valeur
Étendue	Edge
Version	4.5.1
Type	Runtime

API affectées

• EventListener()
• EventListener.EnableEvents(EventSource, EventLevel)
• EventListener.EnableEvents(EventSource, EventLevel, EventKeywords)
• EventListener.EnableEvents(EventSource, EventLevel, EventKeywords, IDictionary<String,String>)

Les implémentations d’EventSource.WriteEvent doivent passer à WriteEvent les mêmes paramètres qu’il a reçus (plus l’ID)

Détails

Le runtime applique à présent le contrat qui stipule ce qui suit : une classe dérivée de System.Diagnostics.Tracing.EventSource qui définit une méthode d'événement ETW doit appeler la méthode EventSource.WriteEvent de la classe de base avec l'ID d'événement suivi des mêmes arguments que ceux passés à la méthode d'événement ETW.

Suggestion

Une exception System.IndexOutOfRangeException est levée si un System.Diagnostics.Tracing.EventListener lit des données System.Diagnostics.Tracing.EventSource dans le processus pour une source d'événement qui ne respecte pas ce contrat.

Nom	Valeur
Étendue	Secondaire
Version	4.5.1
Type	Runtime

API affectées

Non détectable via l’analyse des API.

Les surcharges Marshal.SizeOf et Marshal.PtrToStructure provoquent l’arrêt du code dynamique

Détails

À compter de .NET Framework 4.5.1, la liaison dynamique aux méthodes SizeOf<T>(), SizeOf<T>(T), PtrToStructure(IntPtr, Object), PtrToStructure(IntPtr, Type), PtrToStructure<T>(IntPtr) ou PtrToStructure<T>(IntPtr, T) (via Windows PowerShell, IronPython ou le mot clé dynamic du langage C#, par exemple) peut entraîner des exceptions MethodInvocationExceptions, car de nouvelles surcharges de ces méthodes ont été ajoutées et peuvent être ambiguës pour les moteurs de script.

Suggestion

Mettez à jour les scripts pour indiquer clairement quelle surcharge doit être utilisée. Pour cela, castez explicitement les paramètres de type de la méthode en tant que Type. Cliquez sur ce lien pour plus de détails et d’exemples sur la manière de contourner ce problème.

Nom	Valeur
Étendue	Secondaire
Version	4.5.1
Type	Runtime

API affectées

Non détectable via l’analyse des API.

Certaines API .NET provoquent des exceptions EntryPointNotFoundExceptions de première chance (gérées)

Détails

Dans .NET Framework 4.5, un petit nombre de méthodes .NET levaient des exceptions System.EntryPointNotFoundException de première chance. Ces exceptions étaient gérées dans le .NET Framework, mais pouvaient arrêter l’automatisation des tests, car celle-ci ne s’attendait pas à des exceptions de première chance. Ces mêmes API provoquent l’arrêt de certaines exécutions ApiVerifier lorsque HighVersionLie est activé.

Suggestion

Vous pouvez éviter ce problème en effectuant une mise à niveau vers .NET Framework 4.5.1. Vous pouvez aussi mettre à jour le code d’automatisation des tests pour que son exécution ne soit pas arrêtée en cas d’exceptions System.EntryPointNotFoundException de première chance.

	Valeur
Portée	Edge
Version	4,5
Type	Runtime

API affectées

• Debug.Assert(Boolean)
• Debug.Assert(Boolean, String)
• Debug.Assert(Boolean, String, String)
• Debug.Assert(Boolean, String, String, Object[])
• XmlSerializer(Type)

Les adaptateurs de flux WinRT n’appellent plus FlushAsync automatiquement lors de la fermeture

Détails

Dans les applications du Windows Store, les adaptateurs de flux Windows Runtime n’appellent plus la méthode FlushAsync à partir de la méthode Dispose.

Suggestion

Cette modification devrait être transparente. Les développeurs peuvent rétablir le comportement précédent en écrivant du code comme le suivant :

using (var stream = GetWindowsRuntimeStream() as Stream)
{
// do something
await stream.FlushAsync();
}

Nom	Valeur
Étendue	Mode transparent
Version	4.5.1
Type	Runtime

API affectées

Non détectable via l’analyse des API.

Données

ADO.NET tente maintenant de reconnecter automatiquement les connexions SQL rompues

Détails

À compter de .NET Framework 4.5.1, le .NET Framework tente de reconnecter automatiquement les connexions SQL rompues. Bien que cette opération améliore généralement la fiabilité des applications, il existe des cas particuliers où une application doit savoir que la connexion a été perdue afin de pouvoir prendre des mesures lors de la reconnexion.

Suggestion

Si cette fonctionnalité n’est pas souhaitable pour des raisons de compatibilité, elle peut être désactivée en affectant à la propriété System.Data.SqlClient.SqlConnectionStringBuilder.ConnectRetryCount d’une chaîne de connexion (ou System.Data.SqlClient.SqlConnectionStringBuilder) la valeur 0.

Nom	Valeur
Étendue	Edge
Version	4.5.1
Type	Runtime

API affectées

• IDbConnection.ConnectionString
• SqlConnection.ConnectionString
• ConnectionStringSettings.ConnectionString
• DbConnection.ConnectionString
• DbConnectionStringBuilder.ConnectionString
• SqlConnectionStringBuilder()
• SqlConnectionStringBuilder(String)
• DbConnectionStringBuilder()
• DbConnectionStringBuilder(Boolean)

Sérialisation

NetDataContractSerializer ne parvient pas à désérialiser un ConcurrentDictionary sérialisé avec une autre version de .NET

Détails

Par conception, System.Runtime.Serialization.NetDataContractSerializer peut être utilisé uniquement si les extrémités de sérialisation et de désérialisation partagent toutes deux les mêmes types CLR. Par conséquent, il n’est pas garanti qu’un objet sérialisé avec une version du .NET Framework puisse être désérialisé par une autre version. System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue> est un type qui est connu pour ne pas désérialiser correctement s’il est sérialisé avec .NET Framework 4.5 ou antérieur et désérialisé avec .NET Framework 4.5.1 ou ultérieur.

Suggestion

Il existe un certain nombre de solutions de contournement possibles à ce problème :

• Mettez à niveau l’ordinateur de sérialisation pour utiliser également .NET Framework 4.5.1.
• Utilisez System.Runtime.Serialization.DataContractSerializer au lieu de System.Runtime.Serialization.NetDataContractSerializer, car il n’attend pas les mêmes types CLR à la fois aux extrémités de sérialisation et de désérialisation.
• Utilisez System.Collections.Generic.Dictionary<TKey,TValue> au lieu de System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue>, car il ne présente pas cette rupture particulière entre 4.5->4.5.1.

Nom	Valeur
Étendue	Secondaire
Version	4.5.1
Type	Runtime

API affectées

• NetDataContractSerializer.Deserialize(Stream)

Windows Communication Foundation (WCF)

Le paramètre MinFreeMemoryPercentageToActiveService est désormais pris en compte

Détails

Ce paramètre détermine la mémoire minimale devant être disponible sur le serveur avant l’activation d’un service WCF. Il a pour but de prévenir les exceptions System.OutOfMemoryException. Dans le .NET Framework 4.5, ce paramètre était sans effet. Dans le .NET Framework 4.5.1, ce paramètre est pris en compte.

Suggestion

Une exception se produit si la mémoire disponible sur le serveur web est inférieure au pourcentage défini par le paramètre de configuration. Certains services WCF qui ont réussi à démarrer et à s'exécuter dans un environnement où la mémoire est limitée risquent à présent d'échouer.

Nom	Valeur
Étendue	Secondaire
Version	4.5.1
Type	Runtime

API affectées

Non détectable via l’analyse des API.

Windows Presentation Foundation (WPF)

Le défilement d’un TreeView WPF ou d’un ListBox groupé dans un VirtualizingStackPanel peut empêcher l’application de répondre

Détails

Dans .NET Framework v4.5, le défilement d’un System.Windows.Controls.TreeView WPF dans un panneau de pile virtualisé peut entraîner l’arrêt de la réponse de l’application en cas de marges dans la fenêtre d’affichage (entre les éléments du System.Windows.Controls.TreeView, par exemple, ou sur un élément ItemsPresenter). En outre, dans certains cas, des éléments de taille différente dans une même vue peuvent causer une instabilité, même s’il n’y a pas de marges.

Suggestion

Vous pouvez éviter ce problème en effectuant une mise à niveau vers .NET Framework 4.5.1. Vous pouvez également supprimer les marges des collections de vue (comme les System.Windows.Controls.TreeViews) dans les panneaux d’empilement virtualisés, si tous les éléments qu’ils contiennent sont de même taille.

Nom	Valeur
Étendue	Majeure
Version	4,5
Type	Runtime

API affectées

• VirtualizingStackPanel.SetIsVirtualizing(DependencyObject, Boolean)

.NET Framework 4.5.2

ASP.NET

ASP.NET MVC place désormais dans une séquence d’échappement les espaces dans les chaînes passées via des paramètres d’itinéraire

Détails

Pour des raisons de conformité à la norme RFC 2396, les espaces situés dans les itinéraires de routage sont désormais échappés lors du remplissage des paramètres d’action à partir d’un itinéraire. Par conséquent, alors que /controller/action/some data correspondait au /controller/action/{data} d’itinéraire et fournissait some data comme paramètre de données, il fournit désormais some%20data à la place.

Suggestion

Le code doit être mis à jour pour ne plus échapper les paramètres de chaîne à partir d’un itinéraire. Si l’URI d’origine est nécessaire, vous pouvez y accéder avec l’API RequestUri.OriginalString.

Nom	Valeur
Étendue	Secondaire
Version	4.5.2
Type	Runtime

API affectées

• RouteAttribute(String)

Il n’est plus possible de définir EnableViewStateMac sur false

Détails

ASP.NET ne permet plus aux développeurs de spécifier <pages enableViewStateMac=&quot;false&quot;/> ou <@Page EnableViewStateMac=&quot;false&quot; %>. Le code d'authentification de message (code MAC) de l'état d'affichage est à présent appliqué à toutes les demandes avec état d'affichage intégré. Seules les applications qui définissent explicitement la propriété EnableViewStateMac sur false sont affectées.

Suggestion

Vous devez supposer que la propriété EnableViewStateMac a la valeur true. Les erreurs MAC résultantes doivent être résolues (comme expliqué dans cette aide, qui contient plusieurs résolutions en fonction de l’origine des erreurs MAC).

Nom	Valeur
Étendue	Majeure
Version	4.5.2
Type	Runtime

API affectées

Non détectable via l’analyse des API.

Le profilage des applications ASP.NET MVC4 peut entraîner une erreur irrécupérable du moteur d’exécution

Détails

Les profileurs qui utilisent des assemblys NGEN /profil peuvent planter des applications ASP.NET MVC4 profilées au démarrage avec une exception irrécupérable du moteur d’exécution

Suggestion

Ce problème a été résolu dans .NET Framework 4.5.2. Le profileur peut aussi éviter ce problème en spécifiant COR_PRF_DISABLE_ALL_NGEN_IMAGES dans son masque d’événement.

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

Non détectable via l’analyse des API.

Données

SqlConnection.Open échoue sur Windows 7 si des fournisseurs Winsock BSP ou LSP non-IFS sont installés

Détails

Open() et OpenAsync(CancellationToken) échouent dans .NET Framework 4.5 lors de l’exécution sur un ordinateur Windows 7 si des fournisseurs Winsock BSP ou LSP non-IFS sont installés. Pour déterminer si un fournisseur BSP ou LSP non-IFS est installé, utilisez la commande netsh WinSock Show Catalog et examinez chaque élément Winsock Catalog Provider Entry retourné. Si la valeur des indicateurs de service est définie sur 0x20000, le fournisseur utilise des gestionnaires IFS ce qui lui permet de fonctionner correctement. Si la valeur 0x20000 n’est pas définie, c’est qu’il s’agit d’un BSP ou d’un LSP non IFS.

Suggestion

Ce bogue a été résolu dans le .NET Framework 4.5.2. Vous pouvez donc l’éviter en mettant à niveau votre version du .NET Framework. Vous pouvez également l’éviter en supprimant tous les LSP Winsock non IFS qui sont installés.

Nom	Valeur
Étendue	Secondaire
Version	4,5
Type	Runtime

API affectées

• SqlConnection.Open()
• SqlConnection.OpenAsync(CancellationToken)

Entity Framework

EF ne lève plus d’exception pour des QueryView avec des caractéristiques spécifiques

Détails

Entity Framework ne lève plus une exception System.StackOverflowException quand une application exécute une requête qui implique un QueryView avec une propriété de navigation 0..1 qui tente d’inclure les entités associées dans le cadre de la requête, par exemple en appelant .Include(e => e.RelatedNavProp).

Suggestion

Cette modification affecte uniquement le code qui utilise des QueryView avec des relations 1-0..1 pour exécuter des requêtes qui appellent .Include. Elle permet d'améliorer la fiabilité et doit être transparente pour presque toutes les applications. Toutefois, si elle entraîne un comportement inattendu, vous pouvez la désactiver en ajoutant l'entrée suivante à la section <appSettings> du fichier de configuration de l'application :

<add key="EntityFramework_SimplifyUserSpecifiedViews" value="false" />

Nom	Valeur
Étendue	Edge
Version	4.5.2
Type	Runtime

API affectées

Non détectable via l’analyse des API.

Rupture d’adhésion pour rétrograder de la génération 4.5 de SQL à la génération 4.0 de SQL plus simple

Détails

Les requêtes, qui produisent des instructions JOIN et contiennent un appel à une opération de limitation sans préalablement utiliser OrderBy, produisent à présent un langage SQL plus simple. Après la mise à niveau vers .NET Framework 4.5, ces requêtes produisaient un langage SQL plus compliqué que les versions antérieures.

Suggestion

Cette fonctionnalité est désactivée par défaut. Si Entity Framework génère des instructions JOIN supplémentaires qui entraînent une dégradation des performances, vous pouvez activer cette fonctionnalité en ajoutant l’entrée suivante à la section <appSettings> du fichier de configuration de l’application (app.config) :

<add key="EntityFramework_SimplifyLimitOperations" value="true" />

Nom	Valeur
Étendue	Mode transparent
Version	4.5.2
Type	Runtime

API affectées

Non détectable via l’analyse des API.

Windows Presentation Foundation (WPF)

L’appel de DataGrid.CommitEdit à partir d’un gestionnaire CellEditEnding supprime le focus

Détails

L’appel de CommitEdit() depuis un des gestionnaires d’événements System.Windows.Controls.DataGrid.CellEditEnding de System.Windows.Controls.DataGrid fait que System.Windows.Controls.DataGrid perd le focus.

Suggestion

Ce bogue a été résolu dans le .NET Framework 4.5.2. Vous pouvez donc l’éviter en mettant à niveau votre version du .NET Framework. Vous pouvez également contourner ce problème en resélectionnant explicitement System.Windows.Controls.DataGrid après avoir appelé System.Windows.Controls.DataGrid.CommitEdit().

Nom	Valeur
Étendue	Edge
Version	4,5
Type	Runtime

API affectées

• DataGrid.CommitEdit()
• DataGrid.CommitEdit(DataGridEditingUnit, Boolean)

Impossibilité intermittente de faire défiler jusqu’à l’élément du bas dans les ItemsControls (comme ListBox et DataGrid) lors de l’utilisation de DataTemplates personnalisés

Détails

Dans certains cas, un bogue du .NET Framework 4.5 empêche le défilement des ItemsControls (comme System.Windows.Controls.ListBox, System.Windows.Controls.ComboBox, System.Windows.Controls.DataGrid, etc.) jusqu’au dernier élément quand vous utilisez des DataTemplates personnalisés. Si le défilement est tenté une deuxième fois (après avoir fait défiler jusqu’en haut), il fonctionnera.

Suggestion

Étant donné que ce problème a été résolu dans le .NET Framework 4.5.2, vous pouvez également mettre à niveau votre version du .NET Framework. Vous pouvez également faire glisser les barres de défilement jusqu’au dernier élément de la collection, mais aurez peut-être à recommencer l’opération une deuxième fois pour y arriver.

Nom	Valeur
Étendue	Secondaire
Version	4,5
Type	Runtime

API affectées

Non détectable via l’analyse des API.

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.

XML

Modifications liées à l’analyse XML

Nom	Valeur
Étendue	Secondaire
Version	4.5.2
Type	Runtime

Détails

Pour des raisons de sécurité, les modifications suivantes ont été introduites dans les API d’analyse XML :

• XmlReaderSettings.MaxCharactersFromEntities est défini sur 10 millions quand XmlReaderSettings est initialisé.
• XmlReaderSettings.XmlResolver a la valeur null par défaut.

Notes

XmlReaderSettings est utilisé par tous les analyseurs XML. Par conséquent, bien que cette modification traite le cas XmlReader, elle affecte également d’autres scénarios.

Suggestion

Pour revenir au comportement précédent, vous pouvez définir une valeur dans le Registre. Ajoutez une valeur DWORD nommée EnableLegacyXmlSettings à la clé de Registre HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\XML et définissez sa valeur sur 1. Si vous préférez, vous pouvez également ajouter la valeur de Registre dans la ruche HKEY_CURRENT_USER.

API affectées

• System.Xml.XmlReaderSettings.MaxCharactersFromEntities
• System.Xml.XmlReaderSettings.XmlResolver

En outre, toute API XML qui dépend de XmlResolver, directement ou indirectement, est affectée.