Problèmes de migration du .NET Framework 4

Article
08/10/2011

Cette rubrique décrit les problèmes de migration entre .NET Framework version 3.5 Service Pack 1 et .NET Framework version 4, y compris les correctifs, mises en conformité avec les normes et la sécurité, et modifications basées sur les commentaires des clients. 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 Modifications recommandées du tableau.

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

ASP.NET et Web
Fondamentaux
Données
Windows Communication Foundation (WCF)
Windows Presentation Foundation (WPF)
XML

Pour une vue d'ensemble globale des problèmes dans cette rubrique, consultez Guide de migration du .NET Framework 4.

Pour les problèmes de migration après Bêta 2, consultez Migration Issues for .NET Framework 4 Applications: Beta 2 to RTM.

Pour plus d'informations sur les nouvelles fonctionnalités, consultez Nouveautés de .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)

Fonctionnalité	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 récemment sortis sur le marché et mis à jour. Des navigateurs et appareils anciens (comme Netscape Navigator) ont été supprimés tandis que de nouveaux navigateurs et appareils (comme 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 supprimées, une erreur s'affichera. L'objet HttpBrowserCapabilities (qui est exposé par la propriété Request.Browser de la page) est régi par les fichiers de définition de navigateur. Par conséquent, les informations retournées lors de l'accès à une propriété de cet objet dans ASP.NET 4 peuvent être différentes de celles retournées dans une version antérieure d'ASP.NET.	Si votre application s'appuie sur les anciens fichiers de définitions 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 site Web https://www.asp.net/mobile.
Applications enfants qui fonctionnent sous des versions mixtes d'ASP.NET	Les applications ASP.NET 4 configurées comme enfants d'applications qui exécutent des versions antérieures d'ASP.NET risquent de ne pas démarrer à cause d'erreurs de configuration ou de compilation. L'erreur spécifique qui se produit dépend si l'application s'exécute sous IIS 6.0, IIS 7 ou IIS 7.5.	Vous pouvez apporter des modifications aux fichiers de configuration des applications affectées afin que le système de configuration reconnaisse l'application ASP.NET 4 correctement. Pour plus d'informations sur les modifications que vous devez apporter, consultez la section « ASP.NET 4 Child Applications Fail to Start When Under ASP.NET 2.0 or ASP.NET 3.5 Applications » dans le document ASP.NET 4 Breaking Changes sur le site Web ASP.NET.
Modifications de ClientID	Le nouveau paramètre ClientIDMode dans ASP.NET 4 vous permet de spécifier la façon dont ASP.NET génère l'attribut id pour les éléments HTML. Dans les versions antérieures d'ASP.NET, le comportement par défaut était équivalent au paramètre AutoID de ClientIDMode. Le paramètre par défaut est désormais Predictable. Pour plus d'informations, consultez Identification du contrôle serveur Web ASP.NET.	Si vous utilisez Visual Studio 2010 pour mettre à niveau votre application à partir d'ASP.NET 2.0 ou d'ASP.NET 3.5, l'outil ajoute automatiquement un paramètre au fichier Web.config pour conserver le comportement des versions antérieures du .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 ID client, ajoutez le paramètre suivant au fichier Web.config : <pages ClientIDMode="AutoID" / >
Sécurité d'accès du code (CAS, Code Access Security)	Les fonctionnalités ASP.NET 2.0 ajoutées dans ASP.NET 3.5 utilisent le modèle de sécurité d'accès du code (CAS) .NET Framework 1.1 et .NET Framework 2.0. Toutefois, l'implémentation de la sécurité d'accès du code dans ASP.NET 4 a été considérablement revue. Par conséquent, les applications ASP.NET de confiance partielle qui s'appuient sur du code de confiance exécuté dans le Global Assembly Cache peuvent échouer avec différentes exceptions de sécurité. Les applications de confiance partielle qui s'appuient sur d'importantes modifications apportées à la stratégie CAS de l'ordinateur peuvent également échouer et lever des exceptions de sécurité.	Vous pouvez rétablir le comportement ASP.NET 1.1 et 2.0 pour des applications ASP.NET 4 de confiance partielle en utilisant le nouvel attribut legacyCasModel dans l'élément de configuration trust, comme indiqué dans l'exemple suivant : <trust level= "Medium" legacyCasModel="true" /> Note de sécurité Un rétablissement au modèle CAS antérieur peut entraîner des problèmes de sécurité. Pour plus d'informations sur le nouveau modèle ASP.NET 4 de sécurité d'accès du code, consultez Sécurité d'accès du code dans les applications ASP.NET 4.
Fichiers de configuration	Les fichiers de configuration racine (le fichier machine.config et le fichier racine Web.config) pour le .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 managés, l'exécution d'applications ASP.NET 3.5 sous ASP.NET 4 et sous IIS 7 et IIS 7.5 peut provoquer des erreurs ASP.NET ou des erreurs IIS.	Mettez à niveau vos applications ASP.NET 3.5 vers ASP.NET 4 à l'aide des outils de mise à niveau de projet dans Visual Studio 2010. Visual Studio 2010 modifie automatiquement le fichier Web.config des applications ASP.NET 3.5 pour qu'il contienne les paramètres appropriés pour ASP.NET 4. Toutefois, vous pouvez exécuter des applications ASP.NET 3.5 à l'aide de .NET Framework 4 sans effectuer de 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 ou IIS 7.5. La modification spécifique à effectuer dépend de la combinaison de logiciels que vous utilisez, notamment les versions de Service Pack (SP). Pour plus d'informations sur les éventuelles combinaisons de logiciels affectées par cette modification et sur la résolution de problèmes à l'aide de combinaisons spécifiques, consultez la section « Configuration Errors Related to New ASP.NET 4 Root Configuration » dans le document ASP.NET 4 Breaking Changes sur le site Web ASP.NET.
Rendu des contrôles	Dans les versions antérieures d'ASP.NET, certains contrôles émettaient un balisage que vous ne pouviez pas 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 contrôles Image et ImageButton ne restituent plus d'attribut border="0". La classe BaseValidator et les contrôles de validation dérivés ne restituent plus de texte rouge par défaut. Le contrôle HtmlForm ne restitue pas d'attribut name. Le contrôle Table ne restitue plus d'attribut border="0". Les contrôles qui ne sont pas conçus pour l'entrée d'utilisateur (par exemple, le contrôle Label ) ne restituent plus l'attribut disabled="disabled" si leur propriété Enabled a la valeur false (ou s'ils héritent de ce paramètre d'un contrôle conteneur).	Si vous utilisez Visual Studio 2010 pour mettre à niveau votre application à partir d'ASP.NET 2.0 ou d'ASP.NET 3.5, l'outil ajoute automatiquement un paramètre au fichier Web.config pour conserver 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 action de l'élément HTML form sous la forme d'une chaîne vide lorsqu'une demande est effectuée à une URL sans extension à laquelle est mappé un document par défaut. Dans les premières versions d'ASP.NET, une demande à https://contoso.com entraînait une demande à Default.aspx. Dans ce document, la balise form ouvrante était restituée comme dans l'exemple suivant : <form action="Default.aspx" /> Dans ASP.NET 4, une demande à https://contoso.com entraîne également une demande à Default.aspx, mais ASP.NET restitue maintenant la balise form HTML ouvrante comme dans l'exemple suivant : <form action="" /> Lorsque l'attribut action est une chaîne vide, l'objet IIS DefaultDocumentModule crée une demande enfant à 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, en raison d'une interaction potentielle entre du code managé et le mode intégré IIS 7 ou IIS 7.5, les pages .aspx managées peuvent cesser de fonctionner correctement pendant la demande enfant. Si les conditions suivantes se produisent, la demande enfant à un document .aspx par défaut provoquera une erreur ou un comportement inattendu : Une page .aspx est envoyée au navigateur dont l'attribut action de l'élément form a la valeur "". Le formulaire est publié sur ASP.NET. Un module HTTP managé lit une partie du corps d'entité, tel que 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 d'entité n'est plus disponible pour les modules de code natif qui s'exécutent en mode intégré IIS 7 ou IIS 7.5. L'objet IIS DefaultDocumentModule finit par s'exécuter et crée une demande enfant au 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. Lorsque 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'y a pas de corps d'entité, il n'existe aucune variable de formulaire et aucun état d'affichage. Par conséquent, le gestionnaire de page .aspx ne dispose d'aucune information pour déterminer quel événement doit être déclenché (le cas échéant). Par conséquent, aucun des gestionnaires d'événements de publication pour la page .aspx concernée ne s'exécute.	Pour plus d'informations sur les façons de contourner les problèmes liés à cette modification, consultez la section « Event Handlers Might Not Be Not Raised in a Default Document in IIS 7 or IIS 7.5 Integrated Mode » dans le document ASP.NET 4 Breaking Changes sur le site Web ASP.NET.
Algorithme de hachage	ASP.NET utilise des algorithmes de chiffrement et de hachage pour sécuriser des 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 d'affichage. Les versions antérieures d'ASP.NET utilisaient l'ancien algorithme HMACSHA1.	Si vous exécutez des applications qui combinent ASP.NET 2.0 et ASP.NET 4 (dans lesquelles des données telles que les cookies d'authentification par formulaire doivent fonctionner sous différentes versions du .NET Framework), configurez une application Web ASP.NET 4 pour qu'elle utilise l'ancien algorithme HMACSHA1 en ajoutant le paramètre suivant dans le fichier Web.config : <machineKey validation="SHA1" />
Hébergement de contrôles dans Internet Explorer	Vous ne pouvez plus héberger de contrôles Windows Forms dans Internet Explorer, car il existe de meilleures solutions pour l'hébergement de 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 s'exécuter hors du navigateur. Pour plus d'informations, consultez Out-of-Browser Support. Vous pouvez générer une application du navigateur XAML (XBAP) pour tirer parti de fonctions de WPF (requiert le .NET Framework sur les ordinateurs clients). Pour plus d'informations, consultez Vue d'ensemble des applications de navigateur XAML.
Méthodes HtmlEncode et UrlEncode	Les méthodes HtmlEncode et UrlEncode des classes HttpServerUtility et HttpUtility ont été mises à jour pour encoder le guillemet simple (') comme suit : La méthode HtmlEncode encode les instances du guillemet simple sous la forme ' La méthode UrlEncode encode les instances du guillemet simple sous la forme %27	Dans votre code, recherchez les emplacements où vous utilisez les méthodes HtmlEncode et UrlEncode, et vérifiez que la modification d'encodage ne provoque pas un changement susceptible d'affecter le comportement de votre application.
Erreurs HttpException dans les applications ASP.NET 2.0	Une fois ASP.NET 4 activé sur IIS 6, les applications ASP.NET 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 obligatoire pour exécuter le site Web, remappez le site pour utiliser ASP.NET 2.0 à la place. ou Si ASP.NET 4 est obligatoire pour exécuter le site Web, déplacez tous les répertoires virtuels ASP.NET 2.0 enfants vers un site Web différent mappé à ASP.NET 2.0. ou Désactivez les URL sans extension. Pour plus d'informations, reportez-vous à « ASP.NET 2.0 Applications Might Generate HttpException Errors That Reference eurl.axd » dans le document ASP.NET 4 Breaking Changes sur le site Web ASP.NET.
Types d'appartenance	Certains types (par exemple, System.Web.Security.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 pour résoudre des dépendances de couches architecturales entre des types dans le client et dans des références .NET Framework étendues.	Les bibliothèques de classes mises à niveau à partir de versions antérieures d'ASP.NET et qui utilisent des types d'appartenance déplacés risquent de ne pas être compilées correctement 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 au contrôle Menu	Les modifications au contrôle Menu entraînent le comportement suivant : Si System.Web.UI.WebControls.MenuRenderingMode est défini sur List ou si System.Web.UI.WebControls.MenuRenderingMode est défini sur Default et PagesSection.ControlRenderingCompatibilityVersion est défini sur 4.0 ou ultérieur, la propriété MenuItem.PopOutImageUrl n'a aucun effet. Si le chemin d'accès défini dans les propriétés Menu.StaticPopOutImageUrl et Menu.DynamicPopOutImageUrl contient une barre oblique inverse (\), les images ne sont pas restituées. (Dans les versions antérieures d'ASP.NET, le chemin d'accès peut inclure une barre oblique inverse.)	Au lieu de définir la propriété MenuItem.PopOutImageUrl pour les éléments de menu individuels, définissez le Menu.StaticPopOutImageUrl ou Menu.DynamicPopOutImageUrl du contrôle System.Web.UI.WebControls.Menu parent. ou Définissez System.Web.UI.WebControls.MenuRenderingMode sur Table ou System.Web.UI.WebControls.MenuRenderingMode sur Default et PagesSection.ControlRenderingCompatibilityVersion sur 3.5. Ces paramètres entraînent l'utilisation par le contrôle Menu de la disposition basée sur tableau HTML qu'il a utilisée dans les versions antérieures d'ASP.NET. Si le chemin d'accès dans la propriété Menu.StaticPopOutImageUrl ou Menu.DynamicPopOutImageUrl contient une barre oblique inverse (\), remplacez-la par une barre oblique (/).
Assembly mobile dans le fichier Web.config	Dans les versions antérieures d'ASP.NET, une référence à l'assembly System.Web.Mobile.dll a été incluse dans le fichier Web.config racine dans la section assemblies 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 de cet assembly, ajoutez une référence à l'assembly dans le fichier Web.config racine ou dans un fichier Web.config d'application.
Mise en cache de 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. Par conséquent, les navigateurs clients ne mettaient jamais en cache la page localement. La méthode HttpCachePolicy.SetOmitVaryStar ajoutée dans ASP.NET 1.1 pouvait être appelée pour supprimer l'en-tête Vary:. Toutefois, les rapports de bogues indiquent que les développeurs ignorent le comportement SetOmitVaryStar existant. Dans ASP.NET 4, l'en-tête HTTP Vary: n'est plus émis à partir des réponses qui spécifient la directive suivante : <%@ OutputCache Location="ServerAndClient" %> Par conséquent, la méthode HttpCachePolicy.SetOmitVaryStar n'est plus requise pour supprimer l'en-tête Vary:*. Dans les applications qui spécifient « ServerAndClient » pour l'attribut Location, les pages pourront être mises en cache dans le navigateur sans que vous ayez besoin d'appeler HttpCachePolicy.SetOmitVaryStar.	Si des pages de l'application doivent émettre Vary:, appelez la méthode HttpResponse.AppendHeader comme indiqué dans l'exemple suivant : HttpResponse.AppendHeader("Vary",""); Vous pouvez également modifier l'attribut Location de mise en cache de sortie en lui affectant la valeur "Server".
Analyse de page	L'analyseur de page pour les pages Web ASP.NET (fichiers .aspx) et les contrôles utilisateur (fichiers .ascx) est plus strict dans ASP.NET 4 que dans les versions antérieures d'ASP.NET et il signale plus de balisages comme non valides que dans les versions antérieures.	Examinez les messages d'erreur produits lorsqu'une page s'exécute et corrigez les erreurs qui résultent d'un balisage non valide.
Types Passport	La prise en charge de Passport intégrée à ASP.NET 2.0 est obsolète et n'est plus gérée en raison des modifications apportées à Passport (kit de développement logiciel de Live ID). Par conséquent, les types liés à Passport dans System.Web.Security sont désormais marqués avec l'attribut ObsoleteAttribute.	Modifiez votre code pour qu'il utilise le Kit de développement logiciel Windows Live ID (page éventuellement en anglais) au lieu des types Passport dans l'espace de noms System.Web.Security (par exemple, System.Web.Security.PassportIdentity).
Informations PathInfo dans la propriété FilePath	ASP.NET 4 n'inclut plus la valeur PathInfo dans les valeurs de retour des propriétés comme HttpRequest.FilePath, HttpRequest.AppRelativeCurrentExecutionFilePath et HttpRequest.CurrentExecutionFilePath. À la place, les informations PathInfo sont disponibles dans HttpRequest.PathInfo. Par exemple, imaginez le fragment d'URL suivant : /testapp/Action.mvc/SomeAction Dans les versions antérieures d'ASP.NET, les propriétés System.Web.HttpRequest ont les valeurs suivantes : HttpRequest.FilePath: /testapp/Action.mvc/SomeAction HttpRequest.PathInfo : (vide) Dans ASP.NET 4, les propriétés System.Web.HttpRequest ont plutôt les valeurs suivantes : HttpRequest.FilePath: /testapp/Action.mvc HttpRequest.PathInfo: SomeAction	Dans votre code, recherchez les cas où vous utilisez les propriétés de la classe System.Web.HttpRequest pour retourner des informations sur les chemins d'accès ; modifiez le code pour qu'il soit conforme aux modifications concernant le retour des informations sur les chemins d'accès.
Validation de la demande	Pour améliorer la validation de la demande, la validation de la demande ASP.NET est appelée plus tôt dans le cycle de vie des demandes. Par conséquent, la validation de la demande s'exécute pour les demandes qui ne concernent pas les fichiers .aspx (par exemple, pour les appels de service Web et les gestionnaires personnalisés). Elle est également active lorsque des modules HTTP personnalisés sont exécutés dans le pipeline de traitement des demandes. En raison de cette modification, les demandes de ressources qui ne concernent pas les fichiers .aspx peuvent générer des erreurs de validation de la demande. Du code personnalisé qui s'exécute dans le pipeline de demande (par exemple, des modules HTTP personnalisés) peut également générer des erreurs similaires.	Si nécessaire, vous pouvez revenir à l'ancien comportement qui consiste à déclencher une validation des demandes uniquement pour les pages .aspx. Pour ce faire, utilisez le paramètre suivant dans le fichier de configuration Web : <httpRuntime requestValidationMode="2.0" /> Note de sécurité Si vous rétablissez l'ancien comportement, assurez-vous que tout le code dans les gestionnaires existants, modules et les autres codes personnalisés effectuent des vérifications visant à détecter les entrées HTTP potentiellement dangereuses susceptibles d'être des vecteurs d'attaques XSS.
Routage	Si vous créez un site Web de système de fichiers dans Visual Studio 2010 et que le site Web est situé dans un dossier dont le nom comporte un point (.), les routages d'URL ne fonctionneront pas de manière fiable. Une erreur Http 404 est retournée à partir de certains chemins d'accès virtuel. Cela se produit parce que Visual Studio 2010 lance le serveur Visual Studio Development (Cassini) à l'aide d'un chemin d'accès incorrect pour le répertoire virtuel racine.	Dans la page Propriétés pour le site Web basé sur des fichiers, modifiez l'attribut Virtual Path par « / ». ou Créez un projet d'application Web et non de site Web. Les projets d'application Web n'ont pas ce problème, et le routage d'URL fonctionne même si le nom du dossier du projet contient un point. ou Créez un site Web basé sur Http hébergé dans IIS. Le chemin d'accès virtuel et le dossier de fichier de projet des sites Web hébergés par IIS peuvent contenir un point.
Sites SharePoint	Si vous essayez d'exécuter un site Web ASP.NET 4 déployé comme un enfant d'un site Web SharePoint qui contient un niveau de confiance partielle personnalisé nommé WSS_Minimal, vous obtiendrez l'erreur suivante : 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 essayer d'exécuter un site Web ASP.NET 4 comme un enfant d'un site Web SharePoint.
Normes XHTML 1.1	Pour que les nouveaux sites Web soient conformes à XHTML 1.1, les contrôles ASP.NET dans le .NET Framework 4 généreront un code HTML conforme à XHTML 1.1. Ce rendu est activé à l'aide de l'option suivante dans le fichier Web.config : <system.Web> <pages controlRenderingCompatibilityVersion="4.0"/> </system.Web> Par défaut, cette option est définie sur 4.0. À des fins de compatibilité, le paramètre 3.5 sera activé pour les projets Web mis à niveau à Visual Studio à partir de Visual Studio 2008.	Aucun

Retour au début

Fondamentaux

Fonctionnalités générales

Fonctionnalité	Différences par rapport à la version 3.5 SP1	Modifications recommandées
CardSpace	Windows CardSpace n'est plus inclus dans le .NET Framework ; il est fourni 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 à la façon dont le .NET Framework accède aux fichiers de configuration de l'application.	Si votre fichier de configuration d'application est nommé application-name.config, renommez-le application-name.exe.config. Par exemple, renommez MyApp.config en MyApp.exe.config.
Compilateur de code C#	Les classes Compiler, CompilerError et ErrorLevel qui étaient dans l'espace de noms Microsoft.CSharp ne sont plus disponibles et leur assembly (cscompmgd.dll) n'est plus inclus dans le .NET Framework.	Utilisez la classe CodeDomProvider et d'autres classes dans l'espace de noms System.CodeDom.Compiler. Pour plus d'informations, consultez Utilisation du CodeDOM.
Hébergement (API non managée)	Pour améliorer les fonctions d'hébergement, certaines API d'activation d'hébergement sont déconseillées. Des fonctionnalités d'exécution côte à côte in-process permettent à une application de charger et de démarrer plusieurs versions du .NET Framework dans le même processus. Par exemple, vous pouvez exécuter des applications qui chargent des compléments (ou des composants) basés sur le .NET Framework 2.0 SP1 et des compléments basés sur le .NET Framework 4 dans le même processus. Les composants plus anciens continuent à utiliser la version du .NET Framework plus ancienne, et les nouveaux composants utilisent la nouvelle version de celui-ci.	Utilisez les configurations décrites dans Exécution côte à côte in-process.
Nouveau modèle de sécurité	La stratégie de sécurité d'accès du code (CAS) a été désactivée et remplacée par un modèle simplifié, comme décrit dans Modifications de sécurité dans le .NET Framework 4.	Des modifications peuvent être nécessaires si vos applications dépendent de la sécurité d'accès du code. Pour plus d'informations, consultez Compatibilité de la stratégie de sécurité d'accès du code et migration.

Retour au début

Date et heure

Espace de noms : System ; assembly : mscorlib (dans mscorlib.dll)

Fonctionnalité	Différences par rapport à la version 3.5 SP1	Modifications recommandées
Heures d'été et d'hiver	Pour garantir une cohérence avec l'horloge système, les propriétés d'heure (telles que TimeZoneInfo.Local et DateTime.Now) utilisent maintenant les règles du système d'exploitation au lieu des autres données .NET Framework pour le passage aux heures d'été et d'hiver.	Aucun
Chaînes de mise en forme	Pour prendre en charge la mise en forme dépendante de 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

Retour au début

Globalisation

Pour une liste des nouvelles cultures neutres et spécifiques, consultez Nouveautés en matière de globalisation et de localisation.

Espace de noms : System.Globalization ; assembly : mscorlib (dans mscorlib.dll)

Fonctionnalité	Différences par rapport à la version 3.5 SP1	Modifications recommandées
Noms de cultures	Les modifications de noms suivantes affectent les cultures allemande, maldivienne et africaine : 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 Divehi (Maldives) (dv-MV) est passé de « jj/MMMM/aaaa » à « jj/MM/aaaa ». PMDesignator : L'indicateur PM (APRÈS-MIDI) 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 garantir une cohérence avec le comportement attendu dans les paramètres de serveur Automation, le CLR ne passe plus la culture actuelle pour le paramètre LCID aux applications COM non managées. À la place, il passe 1033 (en-us) pour la culture.	Aucune modification nécessaire sauf pour les applications natives qui requièrent une culture spécifiée.
Types de cultures obsolètes	Les types de cultures FrameworkCultures et WindowsOnlyCultures sont désormais obsolètes. Pour des raisons de compatibilité descendante, FrameworkCultures retourne maintenant les cultures neutres et spécifiques qui étaient incluses dans le .NET Framework précédent, et WindowsOnlyCultures retourne désormais une liste vide.	Utilisez d'autres valeurs de l'énumération CultureTypes.
Récupération de la culture	Depuis Windows 7, .NET Framework 4 recupère les informations de culture à partir du système d'exploitation au lieu de stocker les données lui-même. De plus, le .NET Framework se synchronise avec Windows pour le tri et la casse des données.	Aucun
Normes Unicode 5.1	Le .NET Framework prend désormais en charge tous les caractères Unicode 5.1 (et environ 1400 caractères supplémentaires). Ces nouveaux caractères incluent des symboles, des flèches, des signes diacritiques, des signes de ponctuation, des symboles mathématiques, des idéogrammes et des traits CJC, des chiffres supplémentaires pour le Malayâlam et le Télugu et différents caractères birmans, latins, arabes, grecs, mongols et cyrilliques. Les nouvelles écritures suivantes sont prises en charge avec Unicode 5.1 : sundanais, lepcha, ol tchiki, vaï, saurachtra, kayah li, redjang, gurmukhi, oriya, tamoul, télugu, malayâlam et cham.	Aucun

Retour au début

Exceptions

Espaces de noms : System, System.Runtime.ExceptionServices ; assembly : mscorlib (dans mscorlib.dll)

Fonctionnalité	Différences par rapport à la version 3.5 SP1	Modifications recommandées
Exceptions pour un état de processus endommagé	Le CLR n'envoie plus d'exception pour un état de processus endommagé aux gestionnaires d'exceptions en 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 Handling Corrupted State Exceptions dans le blog Les coulisses du CLR.
Exceptions du moteur d'exécution	ExecutionEngineException est désormais obsolète, car une exception saisissable permettra à un processus instable de continuer à fonctionner. Cette modification améliore la prévisibilité et la fiabilité dans le runtime.	Utilisez un InvalidOperationException pour signaler la condition.

Exceptions pour un état de processus endommagé

Le CLR n'envoie plus d'exception pour un état de processus endommagé aux gestionnaires d'exceptions en 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 Handling Corrupted State Exceptions dans le blog Les coulisses du CLR.

Exceptions du moteur d'exécution

ExecutionEngineException est désormais obsolète, car une exception saisissable permettra à un processus instable de continuer à fonctionner. Cette modification améliore la prévisibilité et la fiabilité dans le runtime.

Utilisez un InvalidOperationException pour signaler la condition.

Retour au début

Réflexion

Espace de noms : System.Reflection ; assembly : mscorlib (dans mscorlib.dll)

Fonctionnalité	Différences par rapport à la version 3.5 SP1	Modifications recommandées
Algorithmes de hachage d'assembly	La propriété AssemblyName.HashAlgorithm retourne désormais AssemblyHashAlgorithm.None, car le runtime ne reconnaî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 Assembly.GetReferencedAssemblies.)	Aucun
Chargement des assemblys	Pour empêcher le chargement redondant des assemblys et enregistrer l'espace d'adressage virtuel, le CLR charge désormais les assemblys à l'aide de la fonction Win32 MapViewOfFile uniquement. De même, il n'appelle plus la fonction LoadLibrary. Cette modification affecte les applications de diagnostic des façons suivantes : Un ProcessModuleCollection ne contiendra plus les modules d'une bibliothèque de classes (fichier .DLL), obtenus grâce à un appel à Process.GetCurrentProcess().Modules. Les applications Win32 qui utilisent la fonction EnumProcessModules ne verront pas tous les modules managés répertoriés.	Aucun
Type déclarant	La propriété Type.DeclaringType retourne désormais la valeur Null correctement 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 lorsqu'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 du Global Assembly Cache	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 assemblys des versions antérieures restent dans l'ancien répertoire. L'énumération ASM_CACHE_FLAGS non managée contient le nouvel indicateur ASM_CACHE_ROOT_EX. Cet indicateur obtient l'emplacement du cache pour les assemblys .NET Framework 4, qui peut être obtenu par la fonction GetCachePath.	Aucune, à condition que les applications n'utilisent pas de chemins d'accès explicites vers les assemblys, ce qui n'est pas recommandé.
Outil Global Assembly Cache	Le 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)

Fonctionnalité	Différences par rapport à la version 3.5 SP1	Modifications recommandées
Longueur de la mémoire tampon (API non managée)	Pour économiser de la mémoire, la fonctionnalité pour le paramètre pBufferLengthOffset de la méthode ICorProfilerInfo2::GetStringLayout a été modifiée pour correspondre au paramètre pStringLengthOffset. Les deux paramètres pointent désormais sur l'emplacement d'offset 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 juste-à-temps	Afin de 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 entraîne le résultat suivant : Vous ne pouvez plus inscrire deux débogueurs différents pour du code managé et natif. Vous ne pouvez plus démarrer automatiquement le débogueur pour un processus non interactif, mais vous pouvez inviter l'utilisateur à suivre un processus interactif. Vous n'êtes plus averti lorsque le débogueur ne peut pas démarrer ou lorsqu'il n'existe aucun débogueur inscrit à démarrer. 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 selon les besoins.
Appel de code non managé	Pour améliorer les performances dans l'interopérabilité avec du code non managé, les conventions d'appel incorrectes dans un appel de code non managé provoquent désormais un é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 2010 vous signalera ces erreurs pour que vous puissiez les corriger. Si vous avez des binaires qui ne peuvent pas être mises à 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 en haut de la pile, comme dans les versions antérieures. Toutefois, cette opération peut affecter les performances de votre application.
Interfaces supprimées (API non managée)	Pour simplifier la tâche des développeurs, les interfaces suivantes ont été supprimées, car elles ne fournissaient aucun scénario d'exécution utile et le CLR ne fournissait ou n'acceptait aucune implémentation : INativeImageINativeImageDependency INativeImageInstallInfo INativeImageEvaluate INativeImageConverter ICorModule IMetaDataConverter	Aucun

Retour au début

Données

Cette section décrit des problèmes de migration pour l'utilisation des groupes de données et des clients SQL, Entity Framework, LINQ to SQL et WCF Data Servers (anciennement appelé ADO.NET Data Services).