Cette page vous a-t-elle été utile ?
Votre avis sur ce contenu est important. N'hésitez pas à nous faire part de vos commentaires.
Vous avez d'autres commentaires ?
1500 caractères restants
Exporter (0) Imprimer
Développer tout
Cet article a fait l'objet d'une traduction manuelle. Déplacez votre pointeur sur les phrases de l'article pour voir la version originale de ce texte. Informations supplémentaires.
Traduction
Source

Compatibilité d'applications dans le .NET Framework 4.5

.NET Framework 4.6 and 4.5

Cette rubrique décrit les problèmes de compatibilité des applications entre .NET Framework 4 et 4.5, y compris les correctifs et les modifications apportés en fonction des commentaires client. La plupart de ces modifications ne requièrent aucun changement dans la programmation de vos applications. Dans les cas où des changements s'avèrent nécessaires, consultez la colonne Impact des tableaux.

Remarque importante Important

Notez que .NET Framework 4.5 n'est pas pris en charge sur Windows XP.

Pour connaître les problèmes de compatibilité entre .NET Framework 4.5 et 4.5.1, consultez Compatibilité d'applications dans le .NET Framework 4.5.1

Cette rubrique décrit des modifications importantes dans les domaines suivants :

Cette rubrique ne traite pas des types et des membres qui ont été déclarés obsolètes dans .NET Framework 4.5. Pour en obtenir la liste, consultez Éléments obsolètes dans la bibliothèque de classes .NET Framework. Pour plus d'informations sur les nouvelles fonctionnalités, voir Nouveautés dans le .NET Framework.

Fonctionnalité

Change

Impact

Méthodes BlockingCollection<T>.TryTakeFromAny(BlockingCollection<T>[], T) et BlockingCollection<T>.TakeFromAny

La méthode BlockingCollection<T>.TryTakeFromAny(BlockingCollection<T>[], T) ne retourne plus la valeur -1 ou ne lève plus d'exception. La méthode BlockingCollection<T>.TakeFromAny ne lève plus d'exception si l'une des collections est marquée comme terminée.

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.

Sérialisation et désérialisation avec la classe System.Runtime.Serialization.Formatters.Soap.SoapFormatter

L'objet Hashtable et les objets de collection ordonnée semblables qui sont sérialisés sous .NET Framework 4.5 ne peuvent pas être désérialisés sous .NET Framework 4.

La classe SoapFormatter ne garantit pas la compatibilité entre les versions. Utilisez les classes System.Runtime.Serialization.Formatters.Binary.BinaryFormatter et System.Runtime.Serialization.NetDataContractSerializer à la place.

[ M:System.Text.RegularExpressions.Regex.CompileToAssembly(System.Text.RegularExpressions.RegexCompilationInfo[],System.Reflection.AssemblyName) ]

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

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 le .NET Framework 4.

  • Utilisez une expression régulière interprétée.

Suppression de System.Threading.Tasks.Task

À l'exception de Task.IAsyncResult.AsyncWaitHandle, les méthodes System.Threading.Tasks.Task ne lèvent plus d'exception 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.

Exceptions non prises en charge dans les opérations System.Threading.Tasks.Task

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 .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 le traitement asynchrone non pris en charge. Le comportement précédent peut être restauré en fournissant un gestionnaire approprié pour l'événement TaskScheduler.UnobservedTaskException.

Méthodes Task.WaitAll avec des arguments de délai d'attente

Dans .NET Framework 4, ces méthodes se comportaient de manière incohérente. 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 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 false.

Dans le .NET Framework 4.5, ces surcharges de méthode retournent désormais 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 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'une autre tâche n'est en cours d'exécution.

Cette modification rend cohérent le comportement de la méthode. Toutefois, il est possible (mais peu probable) que le code d'application dépende des surcharges Task.WaitAll soumises à un délai pour lever une exception lorsqu'au moins une tâche a déjà généré une erreur ou a été annulée avant l'expiration du délai. Dans ce cas, la propriété Task.IsCanceled peut être utilisée à cet effet.

Prise en charge du transfert de type lors du multiciblage

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

Cette modification empêche les avertissements du compilateur (et l'échec de la compilation lorsque les avertissements sont traités comme des erreurs) lorsque CodeDOM trouve deux définitions pour des types qui ont été transférés. Cette modification peut avoir des effets secondaires inattendus seulement si différentes versions des assemblys de référence sont combinées dans un emplacement unique.

[ M:System.Collections.Generic.List`1.ForEach(System.Action{`0}) ]

L'énumérateur lève une exception InvalidOperationException si un élément de la collection est modifié.

Cette modification s'applique uniquement aux applications qui ciblent .NET Framework 4.5 et ne doit pas avoir d'impact négatif. Elle sauvegarde l'intégrité des données et rend l'identification des conditions de concurrence plus probable.

[ T:System.Uri ]

Deux modifications apportées à l'analyse IRI (Identifiant de ressource internationalisée) affectent les URI dans les applications qui ciblent .NET Framework 4.5 :

  • L'élément <iriParsing> est activé par défaut et ne peut pas être désactivé. Auparavant, il était désactivé par défaut.

  • Le formulaire de normalisation Unicode C (NFC) ne sera plus appliqué aux parties non-hôtes des URI. Auparavant, le formulaire NFC était appliqué sur l'ensemble de l'URI lorsque <iriParsing> était activé.

Les URI qui contiennent des noms de fichiers normalisés non NFC (formulaire de normalisation C) ne seront pas normalisés au moyen du formulaire C. L'application peut échouer si l'analyse IRI utilise des chaînes non normalisées pour accéder à des fichiers dotés de noms de fichiers normalisés. Cela affecte uniquement les applications qui ciblent .NET Framework 4.5.

[ T:System.Uri ]

Une URL mailto: non valide lève une exception dans le constructeur de classe Uri.

Cela affecte uniquement les applications qui sont recompilées et qui ciblent .NET Framework 4.5.

[ T:System.Uri ]

Dans les applications qui ciblent .NET Framework 4.5, les points situés à la fin d'un segment de chemin d'accès dans une chaîne URI d'origine (par exemple, http://www.proseware.com/LLC./About.aspx) sont conservés. (Notez que les segments de chemin d'accès qui se composent exactement d'un ou de deux points, tels que http://www.proseware.com/.. ou http://www.proseware.com/./default.htm, sont supprimés, alors que les segments de chemin d'accès incluant plus de deux points consécutifs (tels que http://localhost/dir1/.../dir2) sont conservés.)

Cette modification affecte uniquement les applications qui ciblent .NET Framework 4.5. Les applications qui comptent sur la suppression des points de fin peuvent éventuellement échouer.

[ T:System.Uri ]

Dans les applications qui ciblent le .NET Framework 4.5, les requêtes incluses dans un URI file:// sont autorisées ; le caractère ? n'est pas une séquence d'échappement car il est interprété comme faisant partie du chemin d'accès.

Cette modification affecte uniquement les applications qui ciblent .NET Framework 4.5. Les applications qui comptent sur l'échappement du caractère ? peuvent éventuellement échouer.

[ T:System.Uri ]

Dans les applications qui ciblent .NET Framework 4.5, les caractères de contrôle Unicode de U+0080 à U+009F sont encodés de façon incorrecte.

Normalement, les caractères de contrôle Unicode ne sont pas utilisés dans les URI.

Uri.EscapeDataString , Uri.EscapeUriString et Uri.UnescapeDataString

La liste des caractères réservés et non réservés prend à présent en charge la norme RFC 3986.

Modifications spécifiques :

  • EscapeDataString représente une séquence d'échappement pour les caractères réservés basés sur la norme RFC 3986.

  • EscapeUriString ne représente pas une séquence d'échappement pour les caractères réservés.

  • UnescapeDataString 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.

[ M:System.Threading.Tasks.TaskFactory.FromAsync(System.IAsyncResult,System.Action{System.IAsyncResult}) ]

L'implémentation de la propriété IAsyncResult.CompletedSynchronously doit être correcte pour que la tâche obtenue se termine. Autrement dit, la propriété doit retourner true si, et uniquement si, l'implémentation s'est effectuée de façon synchrone. Auparavant, la propriété n'était pas vérifiée.

La tâche obtenue ne se terminera pas si l'implémentation de la propriété IAsyncResult.CompletedSynchronously retourne true de manière incorrecte.

Hh367887.collapse_all(fr-fr,VS.110).gifSQLClient

Fonctionnalité

Change

Impact

Possibilité de se connecter à une base de données SQL Server à partir du code managé qui s'exécute sous .NET Framework 4.5.

Le chemin d'accès de code API synchrone existant a été modifié pour ajouter la prise en charge asynchrone.

La présence de fournisseurs de service de base Microsoft Winsock BSP (Base Service Provider) ou de fournisseurs de service en couche non-IFS peut interférer avec la capacité à se connecter à SQL Server. Pour plus d'informations, voir L'API SetFileCompletionNotificationModes provoque le dysfonctionnement d'un port de terminaison E/S avec une installation de fournisseur LSP non-IFS sur le site web Aide et Support de Microsoft.

Type System.Data.SqlClient.SqlConnection

Les connexions aux bases de données SQL Server 1997 ne sont plus prises en charge.

Les applications exécutées sous .NET Framework 4.5 ne peuvent pas se connecter aux bases de données SQL Server 1997.

Type System.Data.SqlClient.SqlConnection

Les connexions aux bases de données SQL Server à l'aide du protocole VIA (Virtual Interface Adapter) ne sont plus prises en charge.

Les applications exécutées sous .NET Framework 4.5 ne peuvent pas se connecter aux bases de données SQL Server à l'aide du protocole VIA.

Type System.Data.SqlClient.SqlBulkCopy

Lors de l'insertion de données dans une colonne, 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.

Séquence de classement System.Data.SqlClient

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

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.

Hh367887.collapse_all(fr-fr,VS.110).gifEntity Framework

Fonctionnalité

Change

Impact

Fichiers journaux créés par la méthode ObjectContext.CreateDatabase

Lorsque la méthode 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 est le 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. Elle ne devrait pas avoir d'effets secondaires inattendus.

API DDL (Data Definition Language)

Le comportement des API DDL lorsque AttachDBFilename est spécifié a été modifié comme suit :

  • Les chaînes de connexion n'ont pas besoin de spécifier de valeur Initial Catalog. Auparavant, les valeurs AttatchDBFilename et Initial Catalog étaient requises.

  • Si AttatchDBFilename et Initial Catalog sont spécifiés et si le fichier MDF donné existe, la méthode ObjectContext.DatabaseExists retourne true. Auparavant, elle retournait false.

  • Si AttatchDBFilename et Initial Catalog sont spécifiés et si le fichier MDF donné existe, un appel à la méthode ObjectContext.DeleteDatabase supprime les fichiers.

  • Si la méthode ObjectContext.DeleteDatabase est appelée lorsque la chaîne de connexion spécifie une valeur AttachDBFilename avec un MDF et une valeur Initial Catalog qui n'existent pas, la méthode lève une exception InvalidOperationException. Auparavant, elle levait une exception SqlException.

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 :

Méthodes ObjectContext.CreateDatabase et DbProviderServices.CreateDatabase

Si la création des objets de base de données échoue après qu'une base de données vide a été créée, la méthode tente d'annuler la création de la base de données et propage l'exception SqlException d'origine. Si la tentative d'annulation de la base de données échoue, la méthode lève une exception InvalidOperationException.

Cette modification empêche la création d'une base de données vide et inutilisable. La gestion des exceptions peut changer en partie, car la suppression réussie de la base de données propage désormais l'exception SqlException d'origine.

Méthodes ObjectContext.Translate et ObjectContext.ExecuteStoreQuery

Si T est un type d'énumération, la méthode retourne correctement les données de la base de données. Auparavant, les types d'énumération n'étaient pas pris en charge, si bien que le résultat était toujours casté vers zéro ou converti vers le type d'énumération. Les types sous-jacents qui ne sont pas pris en charge par Entity Framework, tels que UInt16, UInt32 et UInt64, retournent encore zéro ou sont convertis vers le type d'énumération avec une valeur sous-jacente égale à zéro.

La prise en charge des énumérations est une nouveauté d'Entity Framework dans .NET Framework 4.5. Toutefois, si le code du développeur dépend du fait que le résultat soit égal à zéro, cela peut entraîner une erreur d'application, en fonction du code spécifique.

Hh367887.collapse_all(fr-fr,VS.110).gifLINQ

Fonctionnalité

Change

Impact

Méthode Enumerable.Empty<TResult>

La méthode retourne une instance interne mise en cache au lieu de retourner un nouveau type IEnumerable<T>.

Cette modification entraîne une amélioration des performances. Toutefois, le code qui dépend de l'obtention de deux types vides uniques à partir de plusieurs appels à Enumerable.Empty<TResult> échoue.

Fonctionnalité

Change

Impact

Types et membres de l'espace de noms System.Net.PeerToPeer.Collaboration

Les types et les membres ne sont pas pris en charge sur Windows 8. Tenter de les appeler lève une exception PlatformNotSupportedException.

Les applications ne peuvent plus utiliser ces types et membres sur Windows 8.

Fonctionnalité

Change

Impact

MSBuild

Si vous exécutez MSBuild à partir d'une invite de commandes, celui-ci respectera les fichiers de configuration de solution qui désactivent les builds de projets particuliers.

MSBuild se comporte de manière identique lorsqu'il est appelé par Visual Studio et lorsqu'il est exécuté à partir d'une invite de commandes. Vous n'avez pas besoin de créer de solutions distinctes ni de supprimer des projets d'une solution pour générer un sous-ensemble de projets dans une solution.

MSBuild

La propriété TreatAsLocalProperty dans les fichiers projet MSBuild empêche des propriétés spécifiques, y compris la propriété OutDir, d'être substituées à un niveau global.

Les substitutions de la propriété OutDir peuvent provoquer un arrêt potentiel si OutDir est une propriété globale qui est remplacée une fois le fichier MS.Common.Targets importé.

Rapport d'erreurs Windows : compartiments Watson

Les incidents gérés sont regroupés en catégories en fonction d'un certain nombre de critères, dont la version d'assembly. Dans .NET Framework 4.5, la version de fichier est utilisée à la place de la version d'assembly.

Dans la mesure où la version d'assembly change uniquement entre les versions principales, le recours à la version du fichier au lieu de la version d'assembly comme catégorie permet de déterminer la version spécifique d'un assembly impliqué dans un incident géré.

MSBuild

Les données des projets compris dans la collection Microsoft.Build.Evaluation.ProjectCollection ne sont pas automatiquement récupérées par le garbage collector.

Si vous chargez explicitement des projets dans la collection ProjectCollection, vous devez appeler la méthode UnloadProject(Project) pour chaque membre de la collection.

Fonctionnalité

Change

Impact

Outil d'inscription IIS ASP.NET (aspnet_regiis.exe)

Dans Windows 8, les options –i et –u pour installer et désinstaller ASP.NET ne sont pas prises en charge.

Pour installer ou désinstaller ASP.NET 4.5 avec IIS 8, utilisez la boîte de dialogue Activer ou désactiver des fonctionnalités Windows, l'outil de gestion des serveurs ou l'outil en ligne de commande dism.exe.

Contrôle System.Web.UI.WebControls.EntityDataSource

L'événement Page.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 SqlDataSource et 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 Page.LoadComplete.

Méthodes WebUtility.HtmlDecode, WebUtility.UrlDecode et Json.Decode.

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.

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.

Méthode WebUtility.HtmlEncode

Pour les applications qui ciblent .NET Framework 4.5, les caractères extérieurs au plan BMP (Basic Multilingual Plane) effectuent un aller-retour correct lorsqu'ils sont transmis à la méthode WebUtility.HtmlDecode.

Cette modification ne doit avoir aucun effet sur les applications actuelles. Pour rétablir le comportement d'origine, affectez à l'attribut targetFramework de l'élément <httpRuntime> une valeur de chaîne autre que « 4.5 ». Vous pouvez également définir les attributs unicodeEncodingConformance et unicodeDecodingConformance de l'élément de configuration <webUtility> pour contrôler ce comportement indépendamment de la version ciblée du .NET Framework.

Propriété HttpRequest.ContentEncoding

L'encodage UTF-7 est interdit.

Les données des applications qui dépendent des données UTF-7 entrantes ne seront pas décodées correctement dans certains cas. Cela doit être rare, mais vous pouvez restaurer le comportement hérité en utilisant l'attribut aspnet:AllowUtf7RequestContentEncoding de l'élément <appSettings>.

[ M:System.Web.HttpUtility.JavaScriptStringEncode(System.String) ]

Depuis le .NET Framework 4.5, la méthode place le caractère & (et commercial) dans une séquence d'échappement.

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.

Méthodes MachineKey.Encode et MachineKey.Decode

Ces méthodes sont désormais obsolètes.

La compilation du code qui appelle ces méthodes génère un avertissement du compilateur. Les alternatives recommandées sont MachineKey.Protect et MachineKey.Unprotect.

Fonctionnalité

Change

Impact

Applications publiées avec ClickOnce, et qui utilisent un certificat de signature de code SHA-256.

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 à :

  • toutes les applications générées avec Visual Studio 2012 ou une version ultérieure ;

  • toutes les applications générées avec Visual Studio 2010 (ou version antérieure) 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é.

Le changement de signature de l'exécutable ClickOnce affecte uniquement les systèmes Windows Server 2003. Le correctif logiciel KB 938397 doit être installé.

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. Ce problème est résolu dans Visual Studio 2013 Update 3 et dans .NET Framework 4.6 RC. Pour la résolution dans .NET Framework 4.6 RC, consultez Modifications du runtime dans le .NET Framework 4.6.

Fonctionnalité

Change

Impact

System.ComponentModel.Composition.Primitives.ComposablePartCatalog et ses classes dérivées

Depuis .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 XmlSerializer).

La tentative de sérialisation d'un catalogue MEF lève une exception.

Fonctionnalité

Change

Impact

Contrôles d'hébergement du navigateur géré depuis .NET Framework 1.1 et 2.0

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

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 affectant 1 à la valeur EnableIEHosting de la sous-clé de Registre HKLM/SOFTWARE/MICROSOFT/.NETFramework pour les systèmes x86 et pour les processus 32 bits sur les systèmes x64, et en affectant 1 à la valeur EnableIEHosting de la sous-clé de Registre HKLM/SOFTWARE/Wow6432Node/Microsoft/.NETFramework pour les processus 64 bits sur les systèmes x64.

Fonctionnalité

Change

Impact

Messages dans les services web WCF hébergés dans les services Internet (IIS) ou sur le serveur de développement ASP.NET qui dépassent maxRequestLength (dans ASP.NET) ou maxReceivedMessageSize (dans WCF)

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 ProtocolException. Cela inclut les cas dans lesquels le mode de transfert est Streamed.

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.

Replace dans les URL OData

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

Si OData Replace est désactivé (désormais par défaut), la demande de l'utilisateur lèvera une exception et échouera.

[ T:System.ServiceModel.Web.WebServiceHost ]

L'objet System.ServiceModel.Web.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.

Si une application cliente tente de se connecter à un point de terminaison qui n'est plus ajouté par défaut, une erreur HTTP est générée.

Fonctionnalité

Change

Impact

System.Drawing.dll

La propriété CheckForOverflowUnderflow de l'assembly a la valeur true.

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

Constructeur EncoderParameter.EncoderParameter(Encoder, Int32, Int32, Int32)

Le constructeur a été déconseillé.

Le constructeur ne fonctionne pas sur les systèmes 64 bits. Utilisez le constructeur EncoderParameter.EncoderParameter(Encoder, Int32, EncoderParameterValueType, IntPtr) à la place.

Fonctionnalité

Change

Impact

Propriété TextBoxBase.UndoLimit

La limite par défaut du nombre maximal d'opérations d'annulation pour les classes TextBox et RichTextBox est passée de -1 (aucune limite) à 100.

Cette modification ne doit pas avoir d'impact négatif. Toutefois, vous pouvez définir explicitement la propriété UndoLimit après avoir instancié le contrôle.

Énumération System.Windows.Controls.PageRangeSelection

Les membres CurrentPage et SelectedPages ont été ajoutés à l'énumération.

Cette modification ne doit pas avoir d'impact sur les applications existantes. La valeur par défaut est PageRangeSelection.AllPages pour les membres existants qui utilisent cette énumération.

éléments DataTemplate ;

Les éléments DataTemplate apparaissent désormais dans l'affichage de contrôle de l'arborescence UI Automation (UIA).

Cette modification améliore l'accessibilité. Toutefois, elle affecte les outils de test qui s'appuient sur la structure précédente de l'arborescence UIA pour localiser les éléments voisins.

Synchronisation de la propriété TextBox.Text et de la propriété à laquelle elle est associée

Dans certains cas, la propriété TextBox.Text reflète une valeur précédente de la propriété liée aux données si cette propriété est modifiée au cours d'une opération d'écriture de liaison de données.

Cela ne doit pas avoir d'impact négatif. Vous pouvez, cependant, restaurer le comportement précédent en affectant à la propriété FrameworkCompatibilityPreferences.KeepTextBoxDisplaySynchronizedWithTextProperty la valeur false.

Propriété System.Windows.Controls.TextBox

Lorsqu'un contrôle System.Windows.Controls.TextBox est inactif, le texte sélectionné dans la zone s'affiche dans une couleur différente de celle utilisée lorsque la zone de texte est active.

Vous pouvez restaurer le comportement précédent en affectant à la propriété FrameworkCompatibilityPreferences.AreInactiveSelectionHighlightBrushKeysSupported la valeur false.

[ M:System.Windows.Threading.DispatcherSynchronizationContext.CreateCopy ]

Dans .NET Framework 4, la méthode retourne une référence à l'instance actuelle. Dans .NET Framework 4.5, elle retourne une nouvelle instance.

Le code qui suppose que des références égales indiquent que le thread d'exécution est dans le contexte approprié s'exécutera désormais correctement. Toutefois, en raison de la modification, le code qui appelle la méthode DispatcherSynchronizationContext.CreateCopy doit être testé.

Fonctionnalité

Change

Impact

Sécurité System.Activities.dll

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

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

Types et membres WF 3.0

Les types et les membres de WF 3.0 sont désormais marqués comme obsolètes.

Une tentative de compilation d'un code source qui utilise des membres ou des types WF 3.0 génère une erreur du compilateur. Vous devez utiliser les types et les membres WF 4 dans les espaces de noms System.Activities.

Classe System.Activities.Presentation.DragDropHelper

La classe DragDropHelper inclut de nouvelles méthodes qui prennent en charge les opérations glisser-déplacer avec plusieurs objets. Les méthodes glisser-déplacer existantes qui prennent en charge le déplacement d'un seul objet sont obsolètes. (Pour plus d'informations, consultez Éléments obsolètes dans la bibliothèque de classes .NET Framework.)

Bien que les anciennes méthodes aient été déconseillées, elles continuent d'être prises en charge par le compilateur et le Common Langage Runtime. Toutefois, les nouvelles méthodes offrent des fonctionnalités supérieures. Les méthodes recommandées pour remplacer certaines méthodes existantes sont les suivantes :

Résolution de surcharge des appels à la méthode Dispatcher.Invoke

.NET Framework 4.5 ajoute de nouvelles surcharges qui incluent un paramètre de type System.Action. Lorsque le code existant est recompilé, les compilateurs peuvent résoudre les appels aux méthodes Dispatcher.Invoke dotées d'un paramètre Delegate comme des appels aux méthodes Dispatcher.Invoke avec un paramètre System.Action.

Si un appel à une surcharge Dispatcher.Invoke avec un paramètre Delegate est résolu comme un appel à une surcharge Dispatcher.Invoke avec un paramètre System.Action, les différences de comportement suivantes peuvent survenir :

Classe System.Activities.Expressions.Literal<T>

L'objet ValueSerializer associé convertira un objet DateTime ou DateTimeOffset dont les composants Second et Millisecond ne sont pas nuls et (pour une valeur DateTime) dont la propriété DateTime.Kind n'est pas Unspecified en une syntaxe d'élément de propriété au lieu d'une chaîne.

Cette modification permet aux valeurs DateTime et 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.

Fonctionnalité

Change

Impact

Méthode XDocument.Validate

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

Le code de gestion des exceptions qui dépend des valeurs des propriétés XmlSchemaException.LineNumber et XmlSchemaException.LinePosition ne fonctionnera plus.

Chargement des fichiers XML avec System.Xml.XmlTextReader

L'extension d'entité DTD est 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.

Mode de compatibilité ascendante pour la classe System.Xml.Xsl.XslCompiledTransform

Dans .NET Framework 4, la compatibilité ascendante XSLT 1.0 présentait 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 .NET Framework 4.5, ces problèmes ont été résolus et le mode de compatibilité ascendante XSLT 1.0 fonctionne correctement.

Le mode de compatibilité ascendante XSLT 1.0 fonctionne désormais comme auparavant.

Messages d'exception lorsqu'un fichier XSLT est trop complexe

Dans .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 doit pas avoir d'impact réel.

Validation de schéma XML pour xsd:anyURI

Dans .NET Framework 4.5, la validation de schéma XML est plus stricte. Si vous utilisez xsd:anyURI pour valider un URI tel qu'un protocole mailto, la validation échoue si l'URI contient des espaces. Dans les versions antérieures du .NET Framework, la validation réussissait.

La modification affecte uniquement les applications qui ciblent .NET Framework 4.5.

Ajouts de la communauté

AJOUTER
Afficher:
© 2015 Microsoft