Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article décrit les problèmes de migration entre .NET Framework version 3.5 Service Pack 1 et .NET Framework version 4, notamment les correctifs, les modifications pour la conformité et la sécurité des normes, ainsi que les modifications basées sur les commentaires des clients. La plupart de ces modifications ne nécessitent aucune modification de programmation dans vos applications. Pour ceux qui peuvent impliquer des modifications, consultez la colonne Modifications recommandées de la table. Les modifications notables sont réparties par zone, par exemple, ASP.NET et Windows Presentation Foundation (WPF).
Pour obtenir une vue d’ensemble des problèmes de niveau supérieur dans cet article, consultez le Guide de migration vers .NET Framework 4.
Pour plus d’informations sur les nouvelles fonctionnalités, consultez What’s New in .NET Framework 4.
ASP.NET et web
Espaces de noms : System.Web, System.Web.Mobile, System.Web.Security, System.Web.UI.WebControls
Assembly : System.Web (dans System.Web.dll)
| Caractéristique | Différences par rapport à la version 3.5 SP1 | Modifications recommandées |
|---|---|---|
| Fichiers de définition de navigateur | Les fichiers de définition de navigateur ont été mis à jour pour inclure des informations sur les navigateurs et les appareils nouveaux et mis à jour. Des navigateurs et appareils plus anciens tels que Netscape Navigator ont été supprimés, et des navigateurs et appareils plus récents tels que Google Chrome et Apple iPhone ont été ajoutés. Si votre application contient des définitions de navigateur personnalisées qui héritent de l’une des définitions de navigateur qui ont été supprimées, une erreur s’affiche. L'objet HttpBrowserCapabilities (qui est exposé par la propriété Request.Browse de la page) est piloté par les fichiers de définition du navigateur. Par conséquent, les informations retournées en accédant à une propriété de cet objet dans ASP.NET 4 peuvent être différentes des informations retournées dans une version antérieure de ASP.NET. |
Si votre application s’appuie sur les anciens fichiers de définition de navigateur, vous pouvez les copier à partir du dossier suivant : Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers Copiez les fichiers dans le dossier \CONFIG\Browsers correspondant pour ASP.NET 4. Après avoir copié les fichiers, exécutez l’outil en ligne de commande Aspnet_regbrowsers.exe . Pour plus d’informations, consultez le https://www.asp.net/mobile site web. |
| Applications enfants s’exécutant sous des versions mixtes de ASP.NET | ASP.NET 4 applications configurées en tant qu’enfants d’applications qui exécutent des versions antérieures de ASP.NET risquent de ne pas démarrer en raison d’erreurs de configuration ou de compilation. L’erreur spécifique qui se produit varie selon que l’application s’exécute sous IIS 6.0 ou sous IIS 7.5. | Vous pouvez apporter des modifications aux fichiers de configuration des applications affectées afin que le système de configuration reconnaisse correctement l’application ASP.NET 4. Pour plus d’informations sur les modifications que vous devez apporter, consultez la section « Les applications enfants ASP.NET 4 échouent à démarrer lorsqu'elles sont sous ASP.NET 2.0 ou 3.5 » dans le document ASP.NET 4 Modifications importantes sur le site Web ASP.NET. |
| Les modifications de l'identifiant client | Le nouveau clientIDMode paramètre de ASP.NET 4 vous permet de spécifier comment ASP.NET génère l’attribut id pour les éléments HTML. Dans les versions précédentes de ASP.NET, le comportement par défaut était équivalent au AutoID paramètre de clientIDMode. Le paramètre par défaut est maintenant Predictable. Pour plus d’informations, consultez ASP.NET Identification du contrôle de serveur web. |
Si vous utilisez Visual Studio pour mettre à niveau votre application à partir de ASP.NET 2.0 ou ASP.NET 3.5, l’outil ajoute automatiquement un paramètre au fichier Web.config qui conserve le comportement des versions antérieures de .NET Framework. Toutefois, si vous mettez à niveau une application en modifiant le pool d’applications dans IIS pour cibler .NET Framework 4, ASP.NET utilise le nouveau mode par défaut. Pour désactiver le nouveau mode d’ID client, ajoutez le paramètre suivant au fichier Web.config :<pages clientIDMode="AutoID" /> |
| Sécurité de l’accès au code (CAS) | Les fonctionnalités ASP.NET 2.0 qui ont été ajoutées dans ASP.NET 3.5 utilisent le modèle de sécurité d’accès au code de .NET Framework 1.1 et .NET Framework 2.0. Toutefois, la mise en œuvre de la CAS dans ASP.NET 4 a été considérablement repensée. Par conséquent, les applications de confiance partielle ASP.NET qui s’appuient sur du code approuvé s’exécutant dans le Global Assembly Cache peut échouer avec différentes exceptions de sécurité. Les applications à confiance partielle s’appuyant sur des modifications étendues apportées à la stratégie CAS de la machine échouent également, générant des exceptions de sécurité. | Vous pouvez rétablir les applications ASP.NET 4 à approbation partielle au comportement des versions ASP.NET 1.1 et 2.0 à l’aide de l'attribut legacyCasModel nouveau dans l’élément de configuration trust, comme illustré dans l’exemple suivant :<trust level= "Medium" legacyCasModel="true" />Important : le retour à l'ancien modèle CAS peut représenter une réduction de la sécurité. Pour plus d’informations sur le nouveau modèle de sécurité d’accès au code ASP.NET 4, consultez Code Access Security in ASP.NET 4 Applications. |
| Fichiers de configuration | Les fichiers de configuration racine (le fichier machine.config et le fichier Web.config racine) pour .NET Framework et ASP.NET 4 ont été mis à jour pour inclure la plupart des informations de configuration réutilisables qui se trouvaient dans les fichiers d’application Web.config dans ASP.NET 3.5. En raison de la complexité des systèmes de configuration IIS 7 et IIS 7.5 gérés, l’exécution d’applications ASP.NET 3.5 sous ASP.NET 4 et sous IIS 7.5 peut entraîner des erreurs ASP.NET ou des erreurs IIS. | Mettez à niveau ASP.NET applications 3.5 vers ASP.NET 4 à l’aide des outils de mise à niveau de projet dans Visual Studio. Visual Studio 2010 modifie automatiquement le fichier Web.config de l’application ASP.NET 3.5 pour contenir les paramètres appropriés pour ASP.NET 4. Toutefois, vous pouvez exécuter ASP.NET applications 3.5 à l’aide de .NET Framework 4 sans recompilation. Dans ce cas, vous devrez peut-être modifier manuellement le fichier Web.config de l’application avant d’exécuter l’application sous .NET Framework 4 et sous IIS 7.5 ou IIS 7.5. La modification spécifique que vous devez apporter dépend de la combinaison de logiciels avec lesquels vous travaillez, y compris les versions de Service Pack (SP). Pour plus d’informations sur les combinaisons logicielles possibles affectées par cette modification et sur la façon de résoudre les problèmes liés à des combinaisons spécifiques, consultez la section « Erreurs de configuration liées à la nouvelle configuration racine ASP.NET 4 » dans le document Modifications majeures d'ASP.NET 4 sur le site Web ASP.NET. |
| Contrôle du rendu | Dans les versions précédentes de ASP.NET, certains contrôles ont émis le balisage que vous n’avez pas pu désactiver. Par défaut, ce type de balisage n’est plus généré dans ASP.NET 4. Les modifications de rendu affectent les contrôles suivants : * Les Image contrôles et ImageButton ne restituent plus un border="0" attribut.* Les BaseValidator contrôles de classe et de validation qui dérivent de celui-ci ne restituent plus le texte rouge par défaut.* Le HtmlForm contrôle n’affiche pas d’attribut name .* Le Table contrôle n’affiche plus d’attribut border="0" .Les contrôles qui ne sont pas conçus pour l’entrée utilisateur (par exemple, le Label contrôle) ne restituent plus l’attribut disabled="disabled" si leur Enabled propriété est définie false sur (ou s’ils héritent de ce paramètre d’un contrôle de conteneur). |
Si vous utilisez Visual Studio pour mettre à niveau votre application à partir de ASP.NET 2.0 ou ASP.NET 3.5, l’outil ajoute automatiquement un paramètre au fichier Web.config qui conserve le rendu hérité. Toutefois, si vous mettez à niveau une application en modifiant le pool d’applications dans IIS pour cibler .NET Framework 4, ASP.NET utilise le nouveau mode de rendu par défaut. Pour désactiver le nouveau mode de rendu, ajoutez le paramètre suivant au fichier Web.config :<pages controlRenderingCompatibilityVersion="3.5" /> |
| Gestionnaires d’événements dans les documents par défaut | ASP.NET 4 restitue la valeur d’attribut de l’élément form HTML action sous la forme d’une chaîne vide lorsqu’une requête est envoyée à une URL sans extension qui a un document par défaut mappé à celui-ci. Dans les versions antérieures d'ASP.NET, une demande vers http://contoso.com entraînerait une demande vers Default.aspx. Dans ce document, la balise d’ouverture form est affichée comme dans l’exemple suivant :<form action="Default.aspx" />Dans ASP.NET 4, une requête à http://contoso.com entraîne également une requête vers Default.aspx, mais ASP.NET rend désormais la balise d’ouverture HTML form comme dans l’exemple suivant :<form action="" />Lorsque l’attribut action est une chaîne vide, l’objet IIS DefaultDocumentModule crée une requête enfant pour Default.aspx. Dans la plupart des conditions, cette demande enfant est transparente pour le code d’application, et la page Default.aspx s’exécute normalement. Toutefois, une interaction potentielle entre le code managé et le mode intégré IIS 7 ou IIS 7.5 peut entraîner l’arrêt du fonctionnement correct des pages .aspx managées pendant une requête secondaire. Si les conditions suivantes se produisent, une requête secondaire vers un document .aspx par défaut peut entraîner une erreur ou un comportement inattendu :* Une page .aspx est envoyée au navigateur avec l’attribut form de l’élément action défini sur « ».* Le formulaire est retourné à ASP.NET. * Un module HTTP managé lit une partie du corps de l’entité, comme Request.Form ou Request.Params. Le corps d’entité de la demande POST est ainsi lu dans la mémoire managée. Par conséquent, le corps de l’entité n’est plus disponible pour les modules de code natifs qui s’exécutent en mode intégré IIS 7 ou IIS 7.5.* L’objet IIS DefaultDocumentModule s’exécute et crée une requête enfant dans le document Default.aspx. Toutefois, étant donné que le corps d’entité a déjà été lu par une partie du code managé, aucun corps d’entité n’est disponible pour un envoi à la demande enfant.* Quand le pipeline HTTP s’exécute pour la demande enfant, le gestionnaire pour les fichiers .aspx s’exécute pendant la phase d’exécution des gestionnaires. Étant donné qu’il n’existe aucun corps d’entité, il n’existe aucune variable de formulaire et aucun état d’affichage. Par conséquent, il n’existe aucune information disponible pour le gestionnaire de pages .aspx pour déterminer l’événement (le cas échéant) qui doit être déclenché. Par conséquent, aucun des gestionnaires d’événements de postback pour la page .aspx affectée ne s'exécute. |
Pour plus d’informations sur les façons de contourner les problèmes liés à ce changement, consultez la section « Les gestionnaires d’événements peuvent ne pas être déclenchés dans un document par défaut en mode intégré IIS 7 ou IIS 7.5 » dans le document Changements avec rupture dans ASP.NET 4 sur le site web ASP.NET. |
| Algorithme de hachage | ASP.NET utilise des algorithmes de chiffrement et de hachage pour sécuriser les données telles que les cookies d’authentification par formulaire et l’état d’affichage. Par défaut, ASP.NET 4 utilise l’algorithme HMACSHA256 pour les opérations de hachage sur les cookies et l'état de l'affichage. Les versions antérieures de ASP.NET utilisaient l’algorithme plus ancien HMACSHA1 . | Si vous exécutez des applications qui combinent ASP.NET 2.0 et ASP.NET 4, où les données telles que les cookies d’authentification par formulaire doivent fonctionner dans les versions de .NET Framework, configurez une application web ASP.NET 4 pour utiliser l’algorithme plus ancien HMACSHA1 en ajoutant le paramètre suivant dans le fichier Web.config :<machineKey validation="SHA1" /> |
| Contrôles d’hébergement dans Internet Explorer | Vous ne pouvez plus héberger de contrôles Windows Forms dans Internet Explorer, car il existe de meilleures solutions pour héberger des contrôles sur le web. Par conséquent, les assemblys IEHost.dll et IEExec.exe ont été supprimés du .NET Framework. | Vous pouvez utiliser les technologies suivantes pour le développement de contrôles personnalisés dans les applications web : * Vous pouvez créer une application Silverlight et la configurer pour qu’elle s’exécute en dehors du navigateur. Pour plus d'informations, consultez Support hors navigateur. * Vous pouvez créer une application de navigateur XAML (XBAP) pour tirer parti des fonctionnalités WPF (nécessite .NET Framework sur les ordinateurs clients). Pour plus d’informations, consultez vue d’ensemble des applications de navigateur XAML WPF. |
| Méthodes HtmlEncode et UrlEncode | Les méthodes HtmlEncode et UrlEncode des classes HttpUtility et HttpServerUtility ont été mises à jour pour encoder le caractère guillemet simple (') comme suit :* La HtmlEncode méthode encode les instances du guillemet unique en tant que '* La UrlEncode méthode encode les instances du guillemet unique en tant que %27 |
Examinez votre code pour rechercher les emplacements où vous utilisez les HtmlEncode méthodes et UrlEncode les méthodes, et assurez-vous que la modification de l’encodage n’entraîne pas de modification qui affecterait votre application. |
| Erreurs HttpException dans les applications ASP.NET 2.0 | Une fois ASP.NET 4 activé sur IIS 6, ASP.NET applications 2.0 qui s’exécutent sur IIS 6 (dans Windows Server 2003 ou Windows Server 2003 R2) peuvent générer des erreurs telles que les suivantes : System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found. |
* Si ASP.NET 4 n’est pas nécessaire pour exécuter le site Web, remappagez le site pour utiliser ASP.NET 2.0 à la place. - ou - * Si ASP.NET 4 est nécessaire pour exécuter le site Web, déplacez les répertoires virtuels enfants ASP.NET 2.0 vers un autre site Web mappé à ASP.NET 2.0. - ou - * Désactiver les URL sans extension. Pour plus d’informations, consultez « Les applications ASP.NET 2.0 peuvent générer des erreurs HttpException qui font référence à eurl.axd » dans le document ASP.NET 4 Modifications Problématiques sur le site Web d'ASP.NET. |
| Types d’appartenances | Certains types (par exemple, MembershipProvider) utilisés dans l’appartenance ASP.NET ont été déplacés de System.Web.dll vers l’assembly System.Web.ApplicationServices.dll. Les types ont été déplacés afin de résoudre les dépendances liées à la stratification architecturale entre les types du client et ceux présents dans les versions étendues du .NET Framework. | Les bibliothèques de classes qui ont été mises à niveau à partir de versions antérieures de ASP.NET et qui utilisent des types d’appartenances déplacés peuvent échouer à compiler lorsqu’elles sont utilisées dans un projet ASP.NET 4. Si c’est le cas, ajoutez une référence dans le projet de bibliothèque de classes à System.Web.ApplicationServices.dll. |
| Modifications apportées au contrôle de menu | Les modifications apportées au Menu contrôle entraînent le comportement suivant : * Si MenuRenderingMode est défini sur List, ou si MenuRenderingMode est défini sur Default et que ControlRenderingCompatibilityVersion est défini sur 4.0 ou une version ultérieure, la propriété PopOutImageUrl n’a aucun effet.* Si le chemin d’accès défini dans les StaticPopOutImageUrl propriétés et DynamicPopOutImageUrl contient une barre oblique inverse (\), les images ne s’affichent pas. (Dans les versions antérieures d’ASP.NET, le chemin pouvait inclure une barre oblique inverse.) |
* Au lieu de définir la propriété PopOutImageUrl pour des éléments de menu individuels, définissez le StaticPopOutImageUrl ou le DynamicPopOutImageUrl du contrôle parent Menu. - ou - Défini MenuRenderingMode sur Table, ou défini MenuRenderingMode sur Default et défini ControlRenderingCompatibilityVersion sur 3.5. Ces paramètres font que le Menu composant utilise une disposition basée sur des tables HTML, comme celle utilisée dans les versions antérieures d'ASP.NET.* Si le chemin dans la propriété StaticPopOutImageUrl ou DynamicPopOutImageUrl contient une barre oblique inverse (\), remplacez-la par une barre oblique (/). |
| Assemblage mobile dans le fichier Web.config | Dans les versions précédentes d'ASP.NET, une référence à l’assembly System.Web.Mobile.dll a été incluse dans le fichier racine Web.config dans la assemblies section sous system.web/compilation. Pour améliorer les performances, la référence à cet assembly a été supprimée.Remarque : l’assembly System.Web.Mobile.dll et les contrôles mobiles ASP.NET sont inclus dans ASP.NET 4, mais ils sont déconseillés. |
Si vous souhaitez utiliser des types à partir de cet assembly, ajoutez une référence à l’assembly dans le fichier Web.config racine ou dans un fichier de Web.config d’application. |
| Mise en cache de la sortie | Dans ASP.NET 1.0, en raison d’un bogue, les pages mises en cache qui spécifiaient Location="ServerAndClient" en tant que paramètre de cache de sortie émettaient un en-tête HTTP Vary:* dans la réponse. Cela a eu l’effet de dire aux navigateurs clients de ne jamais mettre en cache la page localement. Dans ASP.NET 1.1, la SetOmitVaryStar méthode a été ajoutée, qui peut être appelée pour supprimer l’en-tête Vary:* . Toutefois, les rapports de bogues suggèrent que les développeurs ne connaissent pas le comportement existant SetOmitVaryStar .Dans ASP.NET 4, l’en-tête Vary:* HTTP n’est plus émis à partir de réponses qui spécifient la directive suivante :<%@ OutputCache Location="ServerAndClient" %>Par conséquent, la SetOmitVaryStar méthode n’est plus nécessaire pour supprimer l’en-tête Vary:* . Dans les applications qui spécifient « ServerAndClient » pour l’attribut Location , les pages seront mises en cache dans le navigateur sans exiger que vous appelons SetOmitVaryStar. |
Si les pages de l’application doivent émettre Vary:*, appelez la AppendHeader méthode comme indiqué dans l’exemple suivant :System.Web.HttpResponse.AppendHeader("Vary","*");Vous pouvez également remplacer la valeur de l’attribut de mise en cache Location de sortie par « Server ». |
| Analyse de page | L’analyseur de pages pour ASP.NET pages Web (fichiers .aspx) et les contrôles utilisateur (fichiers .ascx) sont plus stricts dans ASP.NET 4 que dans les versions antérieures de ASP.NET, et il signale plus de balisage que dans les versions antérieures. | Examinez les messages d’erreur générés lorsqu’une page s’exécute et corrigez les erreurs résultant d’un balisage non valide. |
| Types de passeport | La prise en charge de Passport intégrée à ASP.NET 2.0 est obsolète et n’est pas prise en charge en raison des modifications apportées à Passport (désormais kit SDK Live ID). Par conséquent, les types liés à Passport dans System.Web.Security sont maintenant marqués avec l’attribut ObsoleteAttribute. |
Modifiez tout code qui utilise des types Passport dans l’espace System.Web.Security de noms (par exemple PassportIdentity) pour utiliser le Kit de développement logiciel (SDK) Windows Live ID. |
| Informations PathInfo dans la propriété FilePath | ASP.NET 4 n’inclut plus la PathInfo valeur dans les valeurs renvoyées à partir de propriétés telles que FilePath, AppRelativeCurrentExecutionFilePathet CurrentExecutionFilePath. Au lieu de cela, les PathInfo informations sont disponibles dans PathInfo. Par exemple, imaginez le fragment d’URL suivant :/testapp/Action.mvc/SomeActionDans les versions antérieures de ASP.NET, HttpRequest les propriétés ont les valeurs suivantes : * FilePath: /testapp/Action.mvc/SomeAction* PathInfo : (vide) Dans ASP.NET 4, HttpRequest les propriétés ont plutôt les valeurs suivantes : * FilePath: /testapp/Action.mvc* PathInfo: SomeAction |
Examinez votre code pour connaître les emplacements où vous vous appuyez sur les propriétés de la HttpRequest classe pour retourner les informations de chemin d’accès ; modifiez le code pour refléter les modifications apportées à la façon dont les informations de chemin d’accès sont retournées. |
| Validation de la demande | Pour améliorer la validation des demandes, la validation de la demande de ASP.NET est appelée plus tôt dans le cycle de vie de la requête. Par conséquent, la validation des demandes s’exécute pour les requêtes qui ne concernent pas les fichiers .aspx, comme pour les appels de service Web et pour les gestionnaires personnalisés. La validation des demandes est également active lorsque les modules HTTP personnalisés s’exécutent dans le pipeline de traitement des demandes. À la suite de cette modification, les demandes de ressources autres que les fichiers .aspx peuvent générer des erreurs de validation de demande. Le code personnalisé qui s’exécute dans le pipeline de requête (par exemple, les modules HTTP personnalisés) peut également engendrer des erreurs de validation de requête. |
Si nécessaire, vous pouvez revenir à l’ancien comportement d’avoir uniquement .aspx pages qui déclenchent la validation de la demande à l’aide du paramètre suivant dans le fichier de configuration web :<httpRuntime requestValidationMode="2.0" />Avertissement : si vous revenez à l’ancien comportement, assurez-vous que tout le code des gestionnaires, modules et autres codes personnalisés existants effectue des vérifications pour les entrées HTTP potentiellement dangereuses qui peuvent être des vecteurs d’attaque XSS. |
| Routage | Si vous créez un site web de système de fichiers dans Visual Studio 2010 et que le site Web se trouve dans un dossier contenant un point (.) dans le nom du dossier, le routage d’URL ne fonctionne pas de manière fiable. Une erreur HTTP 404 est retournée à partir de certains chemins d’accès virtuels. Cela se produit parce que Visual Studio 2010 lance Visual Studio Development Server à l’aide d’un chemin incorrect pour le répertoire virtuel racine. | * Dans la page Propriétés du site Web basé sur des fichiers, remplacez l’attribut Virtual Path par « / ».- ou - * Créez un projet d’application web au lieu d’un projet de site web. Les projets d’application web n’ont pas ce problème et le routage d’URL fonctionne même si le dossier du projet a un point dans son nom. - ou - * Créez un site web basé sur HTTP hébergé dans IIS. Les sites web hébergés par IIS peuvent avoir des points dans le chemin d’accès virtuel, ainsi que dans le dossier de fichiers projet. |
| Sites SharePoint | Si vous essayez d’exécuter un site web ASP.NET 4 déployé en tant qu’enfant d’un site Web SharePoint qui contient un niveau de confiance partielle personnalisé nommé WSS_Minimal, l’erreur suivante s’affiche :Could not find permission set named 'ASP.Net'. |
Actuellement, aucune version de SharePoint n’est compatible avec ASP.NET. Par conséquent, vous ne devez pas tenter d’exécuter un site web ASP.NET 4 en tant qu’enfant d’un site Web SharePoint. |
| Normes XHTML 1.1 | Pour activer la conformité XHTML 1.1 pour les nouveaux sites Web, les contrôles ASP.NET dans .NET Framework 4 génèrent du code HTML compatible XHTML 1.1. Ce rendu est activé à l’aide de l’option suivante dans le fichier Web.config à l’intérieur de l’élément <system.Web> :<pages controlRenderingCompatibilityVersion="4.0"/>Cette option est définie par défaut sur 4.0. Les projets web mis à niveau à partir de Visual Studio 2008 ont le paramètre 3.5 activé pour la compatibilité. |
Aucun. |
Cœur
Fonctionnalités générales
| Caractéristique | Différences par rapport à la version 3.5 SP1 | Modifications recommandées |
|---|---|---|
| CardSpace | Windows CardSpace n’est plus inclus dans .NET Framework ; elle est fournie séparément. | Téléchargez Windows CardSpace à partir du Centre de téléchargement Microsoft. |
| Fichiers de configuration | Des corrections ont été apportées dans la façon dont .NET Framework accède aux fichiers de configuration d’application. | Si votre fichier de configuration d’application est nommé application-name.config, renommez-le enapplication-name.exe.config. Par exemple, renommez MyApp.config enMyApp.exe.config. |
| Compilateur de code C# | Les classes Compiler, CompilerError et ErrorLevel qui se trouvaient dans l'espace de noms Microsoft.CSharp ne sont plus disponibles, et leur binaire (cscompmgd.dll) n'est plus inclus dans .NET Framework. |
Utilisez la classe CodeDomProvider et d'autres classes dans l'espace de noms System.CodeDom.Compiler. Pour plus d’informations, consultez Utilisation de CodeDOM. |
| Hébergement (API non managée) | Pour améliorer les fonctionnalités d’hébergement, certaines API d’activation d’hébergement ont été déconseillées. Les fonctionnalités d’exécution côte à côte du processus permettent à une application de charger et de démarrer plusieurs versions de .NET Framework dans le même processus. Par exemple, vous pouvez exécuter des applications qui chargent des compléments (ou composants) basés sur .NET Framework 2.0 SP1 et des compléments basés sur .NET Framework 4 dans le même processus. Les anciens composants continuent d’utiliser l’ancienne version du .NET Framework et les nouveaux composants utilisent la nouvelle version du .NET Framework. | Utilisez les configurations décrites dans In-Process exécution côte à côte. |
| Nouveau modèle de sécurité | La stratégie de sécurité de l’accès au code (CAS) a été désactivée et remplacée par un modèle simplifié, comme décrit dans Modifications de sécurité dans .NET Framework 4. | Des modifications pourraient être nécessaires si vous dépendez de CAS dans vos applications. Pour plus d’informations, consultez Compatibilité et migration des stratégies de sécurité d’accès au code. |
Date et heure
Espace de noms : System
Assembly : mscorlib (dans mscorlib.dll)
| Caractéristique | Différences par rapport à la version 3.5 SP1 | Modifications recommandées |
|---|---|---|
| Économies d’été | Pour être cohérent avec l’horloge système, les propriétés d’heure (telles que Local et Now) utilisent désormais des règles de système d’exploitation au lieu d’autres données .NET Framework pour les opérations d’heure d’été. | Aucun. |
| Chaînes de mise en forme | Pour prendre en charge la mise en forme adaptée à la culture, la structure TimeSpan inclut de nouvelles surcharges des méthodes ToString, Parse, et TryParse, en plus des nouvelles méthodes ParseExact et TryParseExact. |
Aucun. |
Mondialisation
Pour obtenir la liste des nouvelles cultures neutres et spécifiques, consultez What’s New in Globalization and Localization.
Espace de noms : System.Globalization
Assembly : mscorlib (dans mscorlib.dll)
| Caractéristique | Différences par rapport à la version 3.5 SP1 | Modifications recommandées |
|---|---|---|
| Noms de culture | Les changements de nom suivants affectent les cultures allemandes, divehi et africaines : * CurrencyEnglishName : le nom de la devise pour la culture Allemand (Suisse) (de-CH) est passé de « sFr. » à « Fr. ». * LongDatePattern : Le modèle de date longue pour la culture Maldivien (Maldives) (dv-MV) est passé de « jj/MMMM/aaaa » à « jj/MM/aaaa ». * PMDesignator : le désignateur P.M. de la culture Afrikaans (Afrique du Sud) (af-ZA) est passé de « nm » à « PM ». |
Notez les changements dans les noms de cultures. |
| Paramètre LCID | Pour être cohérent avec le comportement attendu dans les paramètres du serveur Automation, le CLR ne transmet plus la culture actuelle du LCID paramètre aux applications COM non managées. À la place, il passe 1033 (en-us) pour la culture. |
Aucune modification n’est nécessaire, sauf pour les applications natives qui nécessitent une culture spécifiée. |
| Types de culture obsolètes | Les types de culture CultureTypes et CultureTypes sont désormais obsolètes. Pour la compatibilité descendante, CultureTypes retourne désormais des cultures neutres et spécifiques incluses dans le .NET Framework précédent, et CultureTypes retourne désormais une liste vide. |
Utilisez d’autres valeurs de l’énumération CultureTypes . |
| Récupération de la culture | À compter de Windows 7, .NET Framework 4 récupère les informations de culture du système d’exploitation au lieu de stocker les données elles-mêmes. De plus, .NET Framework se synchronise avec Windows pour le tri et la casse des données. | Aucun. |
| Normes Unicode 5.1 | .NET Framework prend désormais en charge tous les caractères Unicode 5.1 : un ajout d’environ 1400 caractères. Les caractères supplémentaires incluent de nouveaux symboles, flèches, diacritiques, ponctuation, symboles mathématiques, traits et idéogrammes CJK, caractères numériques malayalam et telugu supplémentaires, et divers caractères myanmar, latin, arabe, grec, mongol et cyrillique. Les nouveaux scripts suivants sont pris en charge avec Unicode 5.1 : Sundanese, Lepcha, Ol Chiki, Vai, Saurashtra, Kayah Li, Rejang, Gurmukhi, Odia, Tamil, Telugu et Malayalam caractères et Cham. | Aucun. |
Exceptions
Espaces de noms : System, System.Runtime.ExceptionServices
Assembly : mscorlib (dans mscorlib.dll)
| Caractéristique | Différences par rapport à la version 3.5 SP1 | Modifications recommandées |
|---|---|---|
| Exceptions pour l’état du processus endommagé | Le CLR ne remet plus d’exceptions pour l’état de processus endommagé aux gestionnaires d’exceptions dans le code managé. | Ces exceptions indiquent que l’état d’un processus a été endommagé. Nous vous déconseillons d’exécuter votre application dans cet état. Pour plus d’informations, consultez HandleProcessCorruptedStateExceptionsAttribute et l’entrée Gestion des exceptions d’état endommagé dans le magazine MSDN. |
| Exceptions du moteur d’exécution | ExecutionEngineException est désormais obsolète, car une exception interceptable permet à un processus instable de continuer à s’exécuter. Cette modification améliore la prévisibilité et la fiabilité dans le runtime. | Utilisez un InvalidOperationException indicateur pour signaler la condition. |
Réflexion
Espace de noms : System.Reflection
Assembly : mscorlib (dans mscorlib.dll)
| Caractéristique | Différences par rapport à la version 3.5 SP1 | Modifications recommandées |
|---|---|---|
| Algorithmes de hachage d’assembly | La HashAlgorithm propriété retourne AssemblyHashAlgorithmmaintenant , car le runtime ne connaît pas l’algorithme de hachage de l’assembly référencé lorsque l’assembly n’est pas chargé. (Cela fait référence à l’utilisation de la propriété sur un assembly référencé tel que celui retourné par la méthode GetReferencedAssemblies.) | Aucun. |
| Chargement de l'assemblage | Pour éviter le chargement redondant d’assemblys et pour économiser de l’espace d’adressage virtuel, le CLR charge désormais les assemblys à l’aide uniquement de la fonction Win32 MapViewOfFile . Elle n’appelle plus la fonction LoadLibrary.Cette modification affecte les applications de diagnostic de la manière suivante : * A ProcessModuleCollection ne contiendra plus de modules à partir d’une bibliothèque de classes (fichier.dll), tel qu’obtenu à partir d’un appel à Process.GetCurrentProcess().Modules.* Les applications Win32 qui utilisent la EnumProcessModules fonction ne voient pas tous les modules managés répertoriés. |
Aucun. |
| Déclaration du type | La DeclaringType propriété retourne maintenant correctement null lorsque le type n’a pas de type déclarant. | Aucun. |
| délégués | Un délégué lève maintenant un ArgumentNullException au lieu d’un NullReferenceException quand une valeur Null est passée au constructeur du délégué. | Vérifiez que toutes les gestions d’exceptions interceptent ArgumentNullException. |
| Modification de l’emplacement global du cache d’assembly | Pour les assemblys .NET Framework 4, le global assembly cache a été déplacé du répertoire Windows (%WINDIR%) vers le sous-répertoire Microsoft.Net (%WINDIR%\Microsoft.Net). Les assemblages des versions précédentes demeurent dans le répertoire d'origine. L’énumération ASM_CACHE_FLAGS non managée contient le nouvel ASM_CACHE_ROOT_EX indicateur. Cet indicateur obtient l’emplacement du cache pour les assemblys .NET Framework 4, qui peuvent être obtenus par la fonction GetCachePath . |
Aucune, en supposant que les applications n’utilisent pas de chemins d’accès explicites aux assemblys, ce qui n’est pas une pratique recommandée. |
| Outil Global Assembly Cache | Gacutil.exe (outil Global Assembly Cache) ne prend plus en charge la visionneuse du plug-in du shell. | Aucun. |
Interopérabilité
Espace de noms : System.Runtime.InteropServices
Assembly : mscorlib (dans mscorlib.dll)
| Caractéristique | Différences par rapport à la version 3.5 SP1 | Modifications recommandées |
|---|---|---|
| Longueur de la mémoire tampon (API non managée) | Pour enregistrer la mémoire, la fonctionnalité du pBufferLengthOffset paramètre pour la méthode ICorProfilerInfo2 ::GetStringLayout a été modifiée pour correspondre au pStringLengthOffset paramètre. Les deux paramètres pointent désormais vers l’emplacement de décalage de la longueur de la chaîne. La longueur de la mémoire tampon a été supprimée de la représentation de la classe de chaîne. |
Supprimez toute dépendance sur la longueur de la mémoire tampon. |
| Débogage JIT | Pour simplifier l’inscription pour le débogage juste-à-temps (JIT), le débogueur .NET Framework utilise désormais uniquement la clé de Registre AeDebug, qui contrôle le comportement du débogage JIT pour le code natif. Cette modification se traduit par les éléments suivants : * Vous ne pouvez plus inscrire deux débogueurs différents pour le code managé et natif. * Vous ne pouvez plus démarrer le débogueur automatiquement pour un processus non interactif, mais vous pouvez inviter l’utilisateur à entrer un processus interactif. * Vous n’êtes plus averti lorsque le débogueur ne parvient pas à démarrer ou s’il n’existe aucun débogueur inscrit qui doit être démarré. * Les stratégies de lancement automatique qui dépendent de l’interactivité de l’application ne sont plus prises en charge. |
Ajustez les opérations de débogage en fonction des besoins. |
| Invocation de plateforme | Pour améliorer les performances en matière d’interopérabilité avec du code non managé, les conventions d’appel incorrectes dans un appel de plateforme provoquent maintenant l’échec de l’application. Dans les versions antérieures, la couche de marshaling résolvait ces erreurs en haut de la pile. | Le débogage de vos applications dans Microsoft Visual Studio vous avertit de ces erreurs afin de pouvoir les corriger. Si vous avez des fichiers binaires qui ne peuvent pas être mis à jour, vous pouvez inclure l’élément NetFx40_PInvokeStackResilience< dans le> fichier de configuration de votre application pour permettre la résolution des erreurs d’appel dans la pile comme dans les versions antérieures. Toutefois, cela peut affecter les performances de votre application. |
| Interfaces supprimées (API non managée) | Pour éviter toute confusion des développeurs, les interfaces suivantes ont été supprimées, car elles n’ont fourni aucun scénario d’exécution utile et le CLR n’a pas fourni ni accepté d’implémentations : * INativeImageINativeImageDependency * INativeImageInstallInfo * INativeImageEvaluate * INativeImageConverter * ICorModule * IMetaDataConverter |
Aucun. |
Données
Cette section décrit les problèmes de migration liés à l’utilisation de jeux de données et de clients SQL, entity Framework, LINQ to SQL et WCF Data Servers (anciennement ADO.NET Data Services).
DataSet et SQL Client
Le tableau suivant décrit les améliorations apportées aux fonctionnalités qui avaient précédemment des limitations ou d’autres problèmes.
Espaces de noms : System.Data, System.Data.Objects.DataClasses, System.Data.SqlClient
Assemblys : System.Data (dans System.Data.dll), System.Data.Entity (dans System.Data.Entity.dll)
| Caractéristique | Différences par rapport à la version 3.5 SP1 |
|---|---|
| Scénarios POCO | L’interface IRelatedEnd a de nouvelles méthodes pour améliorer sa facilité d’utilisation dans les scénarios POCO (Plain Old CLR Object). Ces nouvelles méthodes prennent une entité Object au lieu d'une entité IEntityWithRelationships comme paramètre. |
| Modification de lignes | La IndexOf méthode, telle qu’implémentée par la DataView classe, retourne maintenant correctement la valeur d’une ligne en cours de modification, au lieu de renvoyer -1. |
| Événements | L’événement PropertyChanged est maintenant déclenché lorsqu’une ligne est dans un état modifié et que la RejectChanges méthode est appelée. Cette modification facilite la création de contrôles d’interface utilisateur qui exposent le contenu d’un DataSet objet. |
| Exceptions | La méthode Prepare lève maintenant une InvalidOperationException lorsqu'une connexion n'est pas définie ou ouverte, au lieu de lever une NullReferenceException. |
| Vues de cartographie | Les erreurs de mappage des vues de requête sont désormais interceptées au moment de la conception au lieu de lever un NullReferenceException au moment de l’exécution. La validation de mappage intercepte désormais l’erreur dans laquelle deux ensembles d’associations dans le schéma conceptuel (CSDL) sont mappés à la même colonne. |
| Transactions | Si une application essaie d’exécuter une instruction sur une connexion une fois qu’une transaction a été effectuée (voire interrompue ou restaurée), un InvalidOperationException est désormais levé. Les versions précédentes n’ont pas levée d’exception et vous permettent d’exécuter des commandes supplémentaires même si une transaction a été abandonnée. |
Entity Framework
Le tableau suivant décrit les améliorations apportées aux fonctionnalités qui avaient précédemment des limitations ou d’autres problèmes.
Espaces de noms : System.Data, System.Data.Objects, System.Data.Objects.DataClasses
Assemblys : System.Data.Entity (dans System.Data.Entity.dll)
| Caractéristique | Différences par rapport à la version 3.5 SP1 |
|---|---|
| Objets d’entité | Il existe désormais une parité entre la Detach méthode et l’état de l’objet d’entité lorsque la SaveChanges méthode est appelée. Cette cohérence améliorée empêche les exceptions inattendues d’être levées. |
| Entity SQL | Les règles ont été améliorées pour les résolutions d’identificateur dans Entity SQL. L’analyseur Entity SQL a amélioré la logique de résolution des identificateurs multipart. |
| Annotations structurelles | Entity Framework reconnaît désormais les annotations structurelles. |
| Requêtes | Les améliorations suivantes ont été apportées dans les requêtes : * Une GroupBy requête utilisant une clé nulle sur une collection vide ne retourne aucune ligne, même si des sélections supplémentaires sont présentes dans la requête.* Les requêtes SQL générées dans LINQ et Entity-SQL traitent désormais les paramètres de chaîne comme des valeurs non Unicode par défaut. |
LINQ to SQL
Le tableau suivant décrit les améliorations apportées aux fonctionnalités qui avaient précédemment des limitations ou d’autres problèmes.
Espace de noms : System.Data.Linq
Assembly : System.Data.Linq (dans System.Data.Linq.dll)
| Caractéristique | Différences par rapport à la version 3.5 SP1 |
|---|---|
| Événements | Une collection EntitySet<TEntity> déclenche désormais l’événement ListChanged pour des opérations d’ajout et de suppression si EntitySet<TEntity> est déchargé, en plus de déclencher l’événement quand la collection est chargée. |
| Requêtes |
Skip(0) n’est plus ignoré dans les requêtes LINQ to SQL. Par conséquent, les requêtes qui ont cette méthode peuvent se comporter différemment. Par exemple, dans certains cas, une OrderBy clause est requise avec Skip(0), et la requête lève désormais une NotSupportedException exception si la OrderBy clause n’a pas été incluse. |
Services de données WCF
Le tableau suivant décrit les améliorations apportées aux fonctionnalités qui avaient précédemment des limitations ou d’autres problèmes.
Espaces de noms : System.Data.Services, System.Data.Services.Client, System.Data.Services.Common, System.Data.Services.Providers
Assemblys : System.Data.Services (dans System.Data.Services.dll), System.Data.Services.Client (dans System.Data.Services.Client.dll)
| Caractéristique | Différences par rapport à la version 3.5 SP1 |
|---|---|
| Contenu binaire par lots | WCF Data Services prend désormais en charge le contenu binaire par lots dans les requêtes et les réponses. |
| Intercepteurs de changements | Les intercepteurs de changement sont désormais exécutés pour une demande de suppression. Un intercepteur de modification est une méthode qui s’exécute chaque fois qu’une demande est reçue par le serveur pour modifier une entité dans le jeu d’entités. Il fonctionne avant l’exécution de la requête entrante. L’intercepteur de modification fournit l’accès à l’entité en cours de modification et à l’opération en cours d’exécution. |
| Exceptions | Les conditions suivantes lèvent désormais des exceptions plus utiles au lieu de NullReferenceException : * TimeoutException quand un appel à un service de données arrive à expiration. * Un DataServiceRequestException lorsqu'une demande incorrecte est adressée à un service de données. Dans vos applications, vous devez modifier la gestion des exceptions pour intercepter les nouvelles exceptions. |
| En-têtes | Les améliorations suivantes ont été apportées aux en-têtes : * WCF Data Services rejette désormais correctement un eTag en-tête qui a une valeur non spécifiée.* WCF Data Services retourne maintenant une erreur et n’exécute pas la demande de suppression vers un lien lorsqu’un if-* en-tête se trouve dans la requête.* WCF Data Services retourne maintenant une erreur au client au format (Atom, JSON) spécifié dans l’en-tête Accept. |
| Lecteur JSON | Le lecteur JSON (JavaScript Object Notation) retourne désormais une erreur correctement quand il lit une seule barre oblique inverse (« \ ») comme caractère d’échappement, quand il traite des charges JSON envoyées à un service de données WCF. |
| Fusions | Les améliorations suivantes ont été apportées à l’énumération MergeOption : * L’option MergeOption de fusion ne modifie plus l’entité sur le client en raison de toute réponse ultérieure d’un service de données. * L’option MergeOption est désormais cohérente entre les mises à jour dynamiques SQL et celles basées sur des procédures stockées. |
| Demandes | La OnStartProcessingRequest méthode est maintenant appelée avant qu’une demande adressée aux services de données ne soit traitée. Cela permet à la demande de fonctionner correctement pour les ServiceOperation services. |
| Flux | WCF Data Services ne ferme plus le flux sous-jacent pour les opérations de lecture et d’écriture. |
| Uri | L’échappement des URI par le client des services de données WCF a été corrigé. |
Windows Communication Foundation (WCF)
Le tableau suivant décrit les améliorations apportées aux fonctionnalités qui avaient précédemment des limitations ou d’autres problèmes.
| Caractéristique | Différences par rapport à la version 3.5 SP1 |
|---|---|
| Fichiers de configuration | Pour activer l’héritage des comportements via la hiérarchie des fichiers de configuration, WCF prend désormais en charge la fusion entre les fichiers de configuration. Le modèle d’héritage de configuration est maintenant développé pour permettre aux utilisateurs de définir des comportements qui seront appliqués à tous les services en cours d’exécution sur l’ordinateur. Vous pouvez rencontrer des changements comportementaux s’il existe des comportements portant le même nom à différents niveaux de la hiérarchie. |
| Hébergement de service | Vous ne pouvez plus spécifier l’élément <serviceHostingEnvironment> de configuration au niveau du service en ajoutant l’attribut allowDefinition="MachineToApplication" à la définition d’élément.La spécification de l’élément <serviceHostingEnvironment> au niveau du service est techniquement incorrecte et provoque un comportement incohérent. |
Windows Presentation Foundation (WPF)
Applications logicielles
Espaces de noms : System.Windows, System.Windows.Controls
Assemblys : PresentationFramework (dans PresentationFramework.dll)
| Caractéristique | Différences par rapport à la version 3.5 SP1 | Modifications recommandées |
|---|---|---|
| Traitement des exceptions | Pour permettre aux erreurs d'être détectées plus tôt, WPF lève une exception TargetInvocationException et définit la propriété InnerException pour des exceptions critiques, telles que NullReferenceException, OutOfMemoryException, StackOverflowException et SecurityException, au lieu d'intercepter l'exception d'origine. | Aucun. |
| Ressources liées | Pour faciliter la liaison, les fichiers de ressources (tels que les images) situés dans un emplacement autre que la structure de dossiers du projet utilisent le chemin d’accès complet du fichier de ressources au lieu de son nom de fichier comme ID de ressource lorsque l’application est générée. L’application pourra localiser les fichiers au moment de l’exécution. | Aucun. |
| Applications à confiance partielle | Pour des considérations de sécurité, les applications Windows qui s'exécutent avec une confiance partielle et contiennent un contrôle WebBrowser ou un contrôle Frame contenant du code HTML génèrent une exception SecurityException lors de la création du contrôle. Les applications de navigateur lèvent une exception et affichent un message si toutes les conditions suivantes sont remplies : * L’application s’exécute dans Firefox. * L’application s’exécute en confiance partielle dans la zone Internet à partir de sites non approuvés. * L’application contient un WebBrowser contrôle ou un Frame contrôle qui contient du code HTML. Les applications qui s’exécutent à partir de sites approuvés ou de la zone intranet ne seront pas affectées. |
Dans vos applications de navigateur, vous pouvez faciliter cette modification en effectuant l’une des opérations suivantes : * Exécutez l’application de navigateur en toute confiance. * Demandez aux clients d'ajouter le site de l'application à la zone des sites approuvés. |
| Dictionnaires de ressources | Pour améliorer les dictionnaires de ressources au niveau du thème et les empêcher de changer, les ressources gelables définies dans un dictionnaire de ressources et fusionnées dans un dictionnaire au niveau du thème sont désormais toujours congelées et immuables. Il s’agit du comportement attendu pour les ressources gelables. | Les applications qui modifient une ressource définie dans un dictionnaire fusionné au niveau du thème doivent cloner la ressource et modifier la copie cloné. La ressource peut aussi être marquée comme x:Shared="false" pour que ResourceDictionary crée une copie chaque fois que la ressource est interrogée. |
| Windows 7 | Pour améliorer le fonctionnement des applications WPF sur Windows 7, les améliorations suivantes ont été apportées pour corriger le comportement d’une fenêtre : * Les états d’ancrage et de mouvement fonctionnent désormais comme prévu selon les interventions de l’utilisateur. * Les commandes de la barre des tâches Cascade, Afficher les fenêtres empilées et Afficher les fenêtres côte à côte ont désormais le comportement correct et mettent à jour les propriétés appropriées. * Les propriétés Top, Left, Width et Height d'une fenêtre agrandie ou réduite contiennent désormais l'emplacement de restauration correct de la fenêtre, au lieu d'autres valeurs, selon le moniteur. |
Aucun. |
| Style windows et transparence |
InvalidOperationException est levé si vous essayez d’affecter à WindowStyle une valeur différente de WindowStyle quand AllowsTransparency a la valeur true et que WindowState a la valeur WindowState. |
Si vous devez modifier le WindowStyle quand AllowsTransparency est true, vous pouvez appeler la fonction Win32 SetWindowLongPtr. |
| XPS viewer | WPF n’inclut pas microsoft XML Paper Specification Essentials Pack (XPSEP). XPSEP est inclus dans Windows 7 et Windows Vista. Sur un ordinateur exécutant Windows XP sans .NET Framework 3.5 SP1 installé, l’impression à l’aide d’une API WPF autre que ceux de PrintDialog reposera sur WINSPOOL. Certaines fonctionnalités d’imprimante ne sont pas signalées et certains paramètres d’imprimante ne sont pas appliqués lors de l’impression. |
Si nécessaire, installez Microsoft XML Paper Specification Essentials Pack. |
Contrôles
Espaces de noms : System.Windows, System.Windows.Controls, System.Windows.Data, System.Windows.Input
Assemblys : PresentationFramework (en PresentationFramework.dll), PresentationCore (dans PresentationCore.dll), WindowsBase (en WindowsBase.dll)
| Caractéristique | Différences par rapport à la version 3.5 SP1 | Modifications recommandées |
|---|---|---|
| boîtes de dialogue | Pour améliorer la fiabilité, la ShowDialog méthode est appelée sur le même thread que celui qui a créé le FileDialog contrôle. | Veillez à créer un FileDialog contrôle et à appeler la ShowDialog méthode sur le même thread. |
| Fenêtres flottantes | Pour corriger la logique de restauration du focus qui réactive sans cesse une fenêtre flottante (en l’affichant comme une boîte de dialogue modale), la restauration du focus est désormais bloquée si le candidat n’est pas un enfant de la fenêtre. | Aucun. |
| Éléments dans les collections | Lorsqu’un élément est déplacé ou ajouté à une collection sous-jacente, il apparaît dans le CollectionView même emplacement relatif si celui-ci CollectionView n’est pas trié. Cela fournit une cohérence entre la position de l’élément dans la collection et dans la collection associée CollectionView. | Utilisez la méthode ContainerFromItem ou IndexOf pour trouver l’emplacement d’un élément dans un CollectionView au lieu de vous baser sur l’emplacement fixe d’un élément. |
| Dispositions | Pour empêcher toute redisposition inutile, le changement de ShowsNavigationUI n’invalide plus la disposition et n’engendre plus une autre passe de disposition. | Si vous pensez que ShowsNavigationUI provoquera une autre passe de disposition, appelez InvalidateVisual après avoir défini la propriété. |
| menus | Pour activer le texte ClearType dans les fenêtres contextuelles du menu, des modifications ont été apportées à la ControlTemplate classe et au MenuItem contrôle et à d’autres contrôles. | Les applications ne doivent pas s’appuyer sur la structure visuelle des modèles de contrôle. Certaines parties nommées d’un ControlTemplate sont incluses dans le contrat public. Si une application doit trouver un objet spécifique dans un ControlTemplate, recherchez un type spécifique dans l’arborescence visuelle plutôt que de vous fier à un emplacement fixe d'un objet dans l’arborescence. |
| Navigation | Si un Frame navigue directement vers un emplacement, la propriété IsNavigationInitiator est true après la navigation initiale. Cette modification empêche la levée d’événements supplémentaires pendant les scénarios de démarrage. |
Aucun. |
| Fenêtres contextuelles | Le CustomPopupPlacementCallback délégué peut désormais être appelé plusieurs fois pendant une étape de mise en page au lieu d’une seule fois. | Si votre CustomPopupPlacementCallback délégué calcule la position d’un Popup en fonction de sa position précédente, recalculez la position uniquement si les valeurs des paramètres popupSize, targetSize, ou offset changent. |
| Valeurs de propriété | La méthode SetCurrentValue vous permet désormais d’affecter à une propriété une valeur effective même si elle continue de respecter les liaisons, les styles ou les déclencheurs qui affectent la propriété. | Les auteurs de contrôles doivent utiliser SetCurrentValue chaque fois que la valeur de propriété change en tant qu’effet secondaire d’une autre action, y compris la manipulation de l’utilisateur. |
| Zones de texte | Pour des raisons de sécurité, les méthodes Copy et Cut échouent silencieusement lorsqu’elles sont appelées en confiance partielle. En outre, l’exécution programmatique des propriétés Copy ou Cut sur un contrôle qui hérite de TextBoxBase sera bloquée dans un contexte de confiance partielle. Toutefois, les commandes de copie et de coupe initiées par l’utilisateur, telles que cliquer sur un bouton dont Command la propriété est liée à l’une de ces commandes, fonctionneront. Les fonctions standard de copie et de coupe via les raccourcis clavier et le menu contextuel fonctionneront toujours comme avant dans un environnement de confiance partielle. |
Liez la commande Copy ou Cut à une action initiée par l'utilisateur, comme cliquer sur un bouton. |
Graphisme
Espaces de noms : System.Windows, System.Windows.Controls, System.Windows.Data, System.Windows.Input, System.Windows.Media.Effects
Assemblys : PresentationFramework (en PresentationFramework.dll), PresentationCore (dans PresentationCore.dll), WindowsBase (en WindowsBase.dll)
| Caractéristique | Différences par rapport à la version 3.5 SP1 | Modifications recommandées |
|---|---|---|
| Effets bitmap | Pour améliorer les performances, la BitmapEffect classe et les classes qui héritent de la BitmapEffect classe, bien que toujours présentes, sont désactivées. L’effet est affiché à l’aide du pipeline de rendu accéléré par le matériel si les conditions suivantes sont remplies : * L’application utilise un DropShadowBitmapEffect ou un BlurBitmapEffect qui a une propriété de rayon définie à moins de 100 DIU. * La carte vidéo sur l’ordinateur qui exécute l’application prend en charge le nuanceur de pixels 2.0. Si ces conditions ne sont pas remplies, un BitmapEffect objet n’aura aucun effet. En outre, Visual Studio génère un avertissement du compilateur lorsqu’il rencontre l’objet BitmapEffect ou une sous-classe. La PushEffect méthode est marquée comme obsolète. |
Arrêtez d’utiliser les classes héritées BitmapEffect et dérivées et utilisez plutôt les nouvelles classes dérivées de Effect: BlurEffect, DropShadowEffectet ShaderEffect. Vous pouvez également créer vos propres effets en hériter de la ShaderEffect classe. |
| Trames bitmap | Les objets clonés BitmapFrame reçoivent désormais les événements DownloadProgress, DownloadCompleted, et DownloadFailed. Les images téléchargées à partir d’Internet et appliquées au contrôle Image par le biais d’un Style peuvent ainsi fonctionner correctement. Vous verrez un changement de comportement uniquement si toutes les instructions suivantes sont vraies : * Vous vous abonnez à l'événement DownloadProgress, DownloadCompleted, ou DownloadFailed. * La source de l’objet BitmapFrame provient du web. BitmapFrame* Le fichier est cloné pendant que le téléchargement est toujours en cours. |
Vérifiez l’expéditeur dans le gestionnaire d’événements et prenez des mesures uniquement si l’expéditeur est l’expéditeur d’origine BitmapFrame. |
| Décodage d’images | Pour éviter qu’une IOException ne soit pas gérée lorsque les images ne peuvent pas être décodées, la classe BitmapSource déclenche l’événement DecodeFailed lorsqu’elle ne décode pas une image. | Supprimez toute gestion des exceptions pour IOExceptionet utilisez l’événement pour vérifier l’échec DecodeFailed du décodage. |
Entrée
Espaces de noms : System.Windows, System.Windows.Controls, System.Windows.Data, System.Windows.Input
Assemblys : PresentationFramework (en PresentationFramework.dll), PresentationCore (dans PresentationCore.dll), WindowsBase (en WindowsBase.dll)
| Caractéristique | Différences par rapport à la version 3.5 SP1 | Modifications recommandées |
|---|---|---|
| Liaison d’instances de commande | Pour fournir un mécanisme permettant de lier des instances de commande basées sur le modèle de vue aux gestes d’entrée basés sur la vue, la InputBinding classe hérite désormais de Freezable au lieu de DependencyObject. Les propriétés suivantes sont désormais des propriétés de dépendance : * Command * CommandParameter * CommandTarget Cette modification se traduit par les éléments suivants : * Un InputBinding objet est maintenant figé lorsqu’il est inscrit au lieu de rester mutable. * Vous ne pouvez pas accéder aux objets au niveau InputBinding de l’instance à partir de plusieurs threads, en raison des restrictions de la DependencyObject classe. * Vous ne pouvez pas muter de liaisons d’entrée au niveau de la classe après leur inscription, en raison des restrictions de la classe Freezable. * Vous ne pouvez pas spécifier de liaisons d’entrée sur des instances de commande créées dans un modèle d’affichage. |
Créez des instances distinctes d’une InputBinding classe sur des threads distincts si les liaisons doivent être mutables ou figez-les dans le cas contraire. Ne mutez pas une statique InputBinding au niveau de la classe après son inscription. |
| Applications de navigateur | Les applications WPF Browser (.XBAP) traitent désormais les événements de touche comme les applications WPF autonomes, afin que les objets reçoivent des événements de touche routés dans l’ordre correct. | Aucun. |
| Combinaisons de touches mortes | WPF obfusque les clés mortes, qui ne produisent aucun caractère visible, mais indique plutôt que la clé doit être combinée avec la touche de lettre suivante pour produire un caractère. Les événements liés aux touches, tels que l’événement KeyDownEvent, signalent lorsqu’une touche est une touche morte en définissant la propriété Key à la valeur Key. Il s’agit généralement du comportement attendu, car les applications n’ont généralement pas l’intention de répondre à l’entrée du clavier qui crée un caractère combiné. | Les applications qui s'attendent à lire des clés faisant partie de caractères combinés peuvent désormais obtenir la clé masquée à l'aide de la propriété DeadCharProcessedKey. |
| Gestionnaire du focus | Lorsque la FocusManager.GetFocusedElement(DependencyObject) méthode est passée à un élément dont la propriété jointe IsFocusScope est définie true, la méthode renvoie un élément qui est le dernier élément axé sur le clavier dans cette étendue de focus si et uniquement si l’élément retourné appartient au même PresentationSource objet que l’élément passé à la méthode. |
Aucun. |
Automatisation de l'interface utilisateur
Espace de noms : System.Windows, System.Windows.Automation.Peers, System.Windows.Automation.Provider, System.Windows.Controls, System.Windows.Data, System.Windows.Input
Assemblys : PresentationFramework (dans PresentationFramework.dll), PresentationCore (dans PresentationCore.dll), UIAutomationProvider (dans UIAutomationProvider.dll), WindowsBase (dans WindowsBase.dll)
| Caractéristique | Différences par rapport à la version 3.5 SP1 | Modifications recommandées |
|---|---|---|
| Hiérarchie de classes de vues | Les classes TreeViewAutomationPeer et TreeViewItemAutomationPeer héritent de ItemsControlAutomationPeer au lieu de FrameworkElementAutomationPeer. | Si vous héritez des TreeViewItemAutomationPeer classes et remplacez la GetChildrenCore méthode, envisagez de renvoyer un objet qui hérite de la nouvelle TreeViewDataItemAutomationPeer classe. |
| Conteneurs hors écran | Pour corriger une valeur de retour incorrecte, la méthode IsOffscreenCore retourne maintenant correctement false pour des conteneurs d'éléments qui sont défilés hors de vue. En outre, la valeur de la méthode n’est pas affectée par l’occlusion par d’autres fenêtres ou si l’élément est visible sur un moniteur spécifique. |
Aucun. |
| Menus et objets enfants | Pour activer l’automatisation de l’interface utilisateur des menus qui contiennent des enfants autres que des objets de type MenuItem, GetChildrenCore méthode retourne désormais l’objet AutomationPeer d’un objet enfant UIElement, au lieu d’un objet MenuItemAutomationPeer. | Aucun. |
| Nouvelles interfaces et assemblys | Pour activer de nouvelles fonctionnalités pour l’automatisation de l’interface utilisateur, les interfaces suivantes ont été ajoutées : * IItemContainerProvider * ISynchronizedInputProvider * IVirtualizedItemProvider |
Tout projet qui génère des homologues Automation WPF doit ajouter une référence explicite à UIAutomationProvider.dll. |
| Thumb | La GetClassNameCore méthode retourne une valeur au lieu de null. Par conséquent, les contrôles tels que GridSplitter qui héritent de la classe Thumb fourniront un nom à UI Automation. | Aucun. |
| Éléments virtualisés | Pour améliorer les performances, la GetChildrenCore méthode retourne uniquement les objets enfants qui se trouvent réellement dans l’arborescence visuelle, au lieu de tous les objets enfants, qu’ils soient virtualisés ou non. | Utilisez ItemContainerPattern pour itérer sur tous les éléments d’un ItemsControlAutomationPeer. |
XAML
Espaces de noms : System.Windows, System.Windows.Controls, System.Windows.Data, System.Windows.Input, System.Windows.Markup
Assemblys : PresentationFramework (en PresentationFramework.dll), PresentationCore (dans PresentationCore.dll), WindowsBase (en WindowsBase.dll)
| Caractéristique | Différences par rapport à la version 3.5 SP1 | Modifications recommandées |
|---|---|---|
| Extension de balisage | WPF utilise désormais correctement la valeur de la ProvideValue méthode au lieu de renvoyer l’objet MarkupExtension dans certains cas lorsqu’une extension de balisage est utilisée pour définir une propriété ou pour créer un élément dans une collection. Une extension de balisage peut se retourner elle-même dans certains cas. | Si votre application accède à une ressource qui a retourné un objet MarkupExtension dans les versions antérieures, référez-vous à l’objet retourné depuis ProvideValue, au lieu de l’objet MarkupExtension. |
| Analyse des attributs | Les attributs en XAML ne peuvent désormais avoir qu’une seule période. Par exemple, les éléments suivants sont valides :<Button Background="Red"/> (aucun point)<Button Button.Background = "Red"/> (un point)Les éléments suivants ne sont plus valides : <Button Control.Button.Background = "Red"/> (plus d’une période) |
Attributs XAML corrects qui ont plusieurs périodes. |
XML
Les lignes de ce tableau décrivent des améliorations apportées aux fonctionnalités qui avaient précédemment des limitations ou d’autres problèmes.
Schéma et transformations
Espaces de noms : System.Xml.Linq; System.Xml.Schema, System.Xml.XPath
Assemblys : System.Xml (dans System.Xml.dll), System.Xml.Linq (dans System.Xml.Linq.dll)
| Caractéristique | Différences par rapport à la version 3.5 SP1 |
|---|---|
| Schémas Chameleon | Pour empêcher l’altération des données, les schémas caméléon sont désormais clonés correctement lorsqu’ils sont inclus avec plusieurs schémas. Les schémas Chameleon sont des schémas qui n’ont pas d’espace de noms cible et lorsqu’ils sont inclus dans un autre XSD, ils prennent l’espace de noms cible du schéma d’importation. Ils sont souvent utilisés pour inclure des types courants dans un schéma. |
| Fonctions d’ID | La fonction ID XSLT retourne maintenant la valeur correcte au lieu de null lorsqu’un XmlReader objet est passé à un XLST. Si l’utilisateur a créé un objet d’une XmlReader classe LINQ to XML à l’aide de la CreateReader méthode et que cet XmlReader objet a été passé à un XSLT, toutes les instances de la id fonction dans le XSLT renvoyaient précédemment null. Il ne s’agit pas d’une valeur de retour autorisée pour la id fonction. |
| Attribut de namespace | Pour empêcher l’altération des données, un XPathNavigator objet retourne maintenant le nom local de l’attribut x:xmlns correctement. |
| Déclarations d’espace de noms | Un XmlReader objet d’une sous-arborescence ne crée plus de déclarations d’espace de noms dupliquées dans un élément XML. |
| Validation du schéma | Pour empêcher la validation erronée du schéma, la XmlSchemaSet classe permet aux schémas XSD d’être compilés correctement et de manière cohérente. Ces schémas peuvent inclure d’autres schémas ; par exemple, A.xsd peut inclure B.xsd, qui peut inclure C.xsd. Quand l’un d’eux est compilé, ce graphique de dépendances est parcouru. |
| Fonctions de script | La fonction disponible ne retourne false plus de manière incorrecte lorsque la fonction est réellement disponible. |
| Uri | La Load méthode retourne maintenant la baseURI correcte dans les requêtes LINQ. |
Vérification
Espaces de noms : System.Xml.Linq; System.Xml.Schema, System.Xml.XPath
Assemblys : System.Xml (dans System.Xml.dll), System.Xml.Linq (dans System.Xml.Linq.dll)
| Caractéristique | Différences par rapport à la version 3.5 SP1 |
|---|---|
| Résolveurs d’espaces de noms | La méthode ReadContentAs n’ignore plus le résolveur IXmlNamespaceResolver qui lui est passé. Dans les versions précédentes, le programme de résolution d'espace de noms spécifié était ignoré, et XmlReader était utilisé en remplacement. |
| Espace blanc | Pour éviter toute perte de données quand vous créez un lecteur, la méthode Create ne supprime plus l’espace blanc. La validation XML reconnaît le mode de contenu mixte, où le texte peut être mélangé avec le balisage XML. En mode mixte, tous les espaces blancs sont significatifs et doivent être signalés. |
Écriture
Espaces de noms : System.Xml.Linq; System.Xml.Schema, System.Xml.XPath
Assemblys : System.Xml (dans System.Xml.dll), System.Xml.Linq (dans System.Xml.Linq.dll)
| Caractéristique | Différences par rapport à la version 3.5 SP1 |
|---|---|
| Références d’entité | Pour empêcher l’altération des données, les références d’entité ne sont plus entitisées deux fois dans les attributs XML. Si l’utilisateur a essayé d’écrire une entité dans un xmlns attribut ou dans un xml:langxml:space attribut à l’aide de la WriteEntityRef méthode, l’entité a été titisée deux fois dans la sortie, ce qui a endommagé les données. |
| Nouvelle gestion des lignes | Pour empêcher l’altération des données, XmlWriter les objets respectent l’option NewLineHandling . |
Voir aussi
Collaborer avec nous sur GitHub
La source de ce contenu se trouve sur GitHub, où vous pouvez également créer et examiner les problèmes et les demandes de tirage. Pour plus d’informations, consultez notre guide du contributeur.
