Problèmes de migration du .NET Framework 4

Article
04/03/2023

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 mises en conformité avec les normes et la sécurité, et les changements basés sur les commentaires des clients. La plupart de ces modifications ne requièrent aucun changement dans la programmation de vos applications. Si des changements s’avèrent nécessaires, consultez la colonne Changements recommandés du tableau. Les modifications notables sont réparties par zone, par exemple, ASP.NET et Windows Presentation Foundation (WPF).

Pour obtenir une vue d’ensemble globale des problèmes dans cet article, consultez Guide de migration vers .NET Framework 4.

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 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’affiche. L’objet HttpBrowserCapabilities (qui est exposé par la propriété `Request.Browse` de la page) est régi par les fichiers de définition de navigateur. Les informations retournées durant l’accès à une propriété de cet objet dans ASP.NET 4 peuvent donc être différentes de celles retournées dans une version antérieure d’ASP.NET.	Si votre application repose 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 s’exécutent 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 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, IIS 7 ou IIS 7.5.	Vous pouvez apporter des changements aux fichiers de configuration des applications affectées pour que le système de configuration reconnaisse l’application ASP.NET 4 correctement. Pour plus d’informations sur les changements que vous devez effectuer, consultez la section « Échec du démarrage des applications enfants ASP.NET 4 sous des applications ASP.NET 2.0 ou ASP.NET 3.5 » dans le document Changements avec rupture dans ASP.NET 4 sur le site web ASP.NET.
Changements 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 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 de .NET Framework. Toutefois, si vous mettez à niveau une application en changeant 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)	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) du .NET Framework 1.1 et du .NET Framework 2.0. Toutefois, l’implémentation de CAS dans ASP.NET 4 a été considérablement revue. Ainsi, 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" />` Important : Le rétablissement du 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 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 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. 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 le .NET Framework 4 et sous IIS 7 ou IIS 7.5. Le changement spécifique à effectuer dépend de la combinaison de logiciels que vous utilisez, notamment les mises en production des Service Pack (SP). Pour plus d’informations sur les éventuelles combinaisons de logiciels affectées par ce changement et sur la résolution de problèmes à l’aide de combinaisons spécifiques, consultez la section « Erreurs de configuration liées à la nouvelle configuration racine d’ASP.NET 4 » dans le document Changements avec rupture dans ASP.NET 4 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 changements de rendu affectent les contrôles suivants : * Les contrôles `Image` et `ImageButton` n’affichent plus d’attribut `border="0"`. * La classe `BaseValidator` et les contrôles de validation dérivés n’affichent plus de texte rouge par défaut. * Le contrôle `HtmlForm` n’affiche pas d’attribut `name`. * Le contrôle `Table` n’affiche 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`) n’affichent plus d’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 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 changeant 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 affiche la valeur d’attribut `action` de l’élément HTML `form` sous la forme d’une chaîne vide quand une demande est effectuée à une URL sans extension à laquelle est mappé un document par défaut. Dans les premières mises en production d’ASP.NET, une demande à `http://contoso.com` entraînait une demande à Default.aspx. Dans ce document, la balise `form` ouvrante était affichée comme dans l’exemple suivant : `<form action="Default.aspx" />` Dans ASP.NET 4, une demande à `http://contoso.com` entraîne également une demande à Default.aspx, mais ASP.NET affiche maintenant la balise HTML `form` ouvrante comme dans l’exemple suivant : `<form action="" />` Quand 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 le 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 provoque 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. Le corps d’entité n’est donc 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. * 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’y a pas de corps d’entité, il n’existe aucune variable de formulaire et aucun état d’affichage. Le gestionnaire de page .aspx ne dispose donc d’aucune information pour déterminer l’événement à déclencher (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 à 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 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. Les assemblys IEHost.dll et IEExec.exe ont donc été supprimés de .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 Prise en charge hors navigateur. * Vous pouvez générer une application du 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.
Méthodes HtmlEncode et UrlEncode	Les méthodes `HtmlEncode` et `UrlEncode` des classes HttpUtility et HttpServerUtility 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 le changement 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, comme celle-ci : `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 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 autre site web mappé à ASP.NET 2.0. -ou- * Désactivez les URL sans extension. Pour plus d’informations, consultez « Les applications ASP.NET 2.0 peuvent générer des erreurs HttpException qui référencent eurl.axd » dans le document Changements avec rupture dans ASP.NET 4 sur le site web ASP.NET.
Types d’appartenance	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 pour résoudre des dépendances de couches architecturales entre des types dans le client et dans des références SKU .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 quand 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.
Changements apportés au contrôle Menu	Les changements apportés au contrôle Menu entraînent le comportement suivant : * Si MenuRenderingMode a la valeur `List` ou si MenuRenderingMode a la valeur `Default` et ControlRenderingCompatibilityVersion la valeur `4.0` ou supérieure, la propriété PopOutImageUrl n’a aucun effet. * Si le chemin défini dans les propriétés StaticPopOutImageUrl et DynamicPopOutImageUrl contient une barre oblique inverse (\), les images ne sont pas affichées. (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 les éléments de menu individuels, définissez le StaticPopOutImageUrl ou DynamicPopOutImageUrl du contrôle Menu parent. -ou- Affectez à MenuRenderingMode la valeur `Table` ou affectez à MenuRenderingMode la valeur `Default` et affectez à ControlRenderingCompatibilityVersion la valeur `3.5`. Ces paramètres entraînent l’utilisation par le contrôle Menu de la disposition basée sur un tableau HTML qu’il a 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 (/).
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 était 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éprécié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 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. Les navigateurs clients ne mettaient donc jamais en cache la page localement. La méthode 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" %>` La méthode SetOmitVaryStar n’est donc plus exigée pour supprimer l’en-tête `Vary:`. Dans les applications qui spécifient « ServerAndClient » pour l’attribut `Location`, les pages peuvent être mises en cache dans le navigateur sans que vous ayez besoin d’appeler SetOmitVaryStar.	Si des pages de l’application doivent émettre `Vary:`, appelez la méthode AppendHeader comme indiqué dans l’exemple suivant : `System.Web.HttpResponse.AppendHeader("Vary","");` Vous pouvez également affecter à l’attribut `Location` de mise en cache de sortie la valeur « Server ».
Analyses de pages	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 quand 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 changements effectués dans Passport (à présent SDK Live ID). Les types liés à Passport dans System.Web.Security sont donc désormais marqués avec l’attribut `ObsoleteAttribute`.	Changez votre code pour qu’il utilise le SDK Windows Live ID au lieu des types Passport dans l’espace de noms System.Web.Security (par exemple, 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 FilePath, AppRelativeCurrentExecutionFilePath et CurrentExecutionFilePath. À la place, les informations `PathInfo` sont disponibles dans 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 HttpRequest ont les valeurs suivantes : * FilePath: `/testapp/Action.mvc/SomeAction` * PathInfo : (vide) Dans ASP.NET 4, les propriétés HttpRequest ont plutôt les valeurs suivantes : * FilePath: `/testapp/Action.mvc` * PathInfo: `SomeAction`	Dans votre code, recherchez les cas où vous utilisez les propriétés de la classe HttpRequest pour retourner des informations sur les chemins ; changez le code pour qu’il soit conforme aux changements concernant le retour des informations sur les chemins.
Validation des demandes	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. La validation de la demande s’exécute donc 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 quand des modules HTTP personnalisés sont exécutés dans le pipeline de traitement des demandes. En raison de ce changement, les demandes de ressources qui ne concernent pas les fichiers .aspx peuvent générer des erreurs de validation de la demande. Le 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" />` Avertissement : Si vous rétablissez l’ancien comportement, vérifiez 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 fonctionnent pas de manière fiable. Une erreur HTTP 404 est retournée à partir de certains chemins virtuels. Cela se produit parce que Visual Studio 2010 lance le serveur Visual Studio Development à l’aide d’un chemin incorrect pour le répertoire virtuel racine.	* Dans la page Propriétés pour le site web basé sur des fichiers, remplacez l’attribut Chemin virtuel 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 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 obtenez l’erreur suivante : `Could not find permission set named 'ASP.Net'.`	À l’heure actuelle, aucune version de SharePoint n’est compatible avec ASP.NET. Vous ne devez donc pas essayer d’exécuter un site web ASP.NET 4 comme enfant d’un site web SharePoint.
Standards XHTML 1.1	Pour que les nouveaux sites web soient conformes à XHTML 1.1, les contrôles ASP.NET dans .NET Framework 4 génèrent un code HTML conforme à XHTML 1.1. Ce rendu est activé à l’aide de l’option suivante dans le fichier Web.config dans l’élément `<system.Web>` : `<pages controlRenderingCompatibilityVersion="4.0"/>` Cette option a la valeur 4.0 par défaut. À des fins de compatibilité, le paramètre 3.5 sera activé pour les projets web mis à niveau à partir de Visual Studio 2008.	Aucune.

Core

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 .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 .NET Framework accède aux fichiers de configuration de l’application.	Si votre fichier de configuration d’application se nomme 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 .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 ont été dépréciées. Des fonctionnalités d’exécution côte à côte in-process 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 des 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 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 .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.

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
Heure d’été	Pour garantir une cohérence avec l’horloge système, les propriétés d’heure (telles que Local et 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.	Aucune.
Mise en forme des chaînes	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`.	Aucune.

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 changements de noms suivants 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 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 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’est nécessaire, sauf pour les applications natives qui nécessitent une culture spécifiée.
Types de cultures obsolètes	Les types de cultures CultureTypes et CultureTypes sont désormais obsolètes. Pour des raisons de compatibilité descendante, CultureTypes retourne maintenant les cultures neutres et spécifiques qui étaient 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 à partir du système d’exploitation au lieu de stocker les données lui-même. De plus, .NET Framework se synchronise avec Windows pour le tri et la casse des données.	Aucune.
Standards Unicode 5.1	.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élougou et différents caractères birmans, latins, arabes, grecs, mongols et cyrilliques. Les nouveaux scripts suivants sont pris en charge avec Unicode 5.1 : sundanais, lepcha, ol tchiki, vaï, saurachtra, kayah li, redjang, gurmukhi, odia, tamoul, télougou, malayalam et cham.	Aucune.

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 en cas d’état de processus altéré	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 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 saisissable permettra à un processus instable de continuer à fonctionner. Ce changement améliore la prévisibilité et la fiabilité dans le runtime.	Utilisez un InvalidOperationException pour signaler la condition.

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é HashAlgorithm retourne désormais AssemblyHashAlgorithm, car le runtime ne reconnaît pas l’algorithme de hachage de l’assembly référencé quand 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.)	Aucune.
Chargement d’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`. Ce changement affecte les applications de diagnostic des façons suivantes : * Un ProcessModuleCollection ne contient 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 voient pas tous les modules managés répertoriés.	Aucune.
Type déclarant	La propriété DeclaringType retourne désormais la valeur Null correctement quand le type n’a pas de type déclarant.	Aucune.
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.
Changement d’emplacement du Global Assembly Cache	Pour les assemblys .NET Framework 4, le Global Assembly Cache a été déplacé du répertoire Windows (%WINDIR%) dans 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 explicites vers les assemblys, ce qui n’est pas recommandé.
Outil Global Assembly Cache	Gacutil.exe (outil Global Assembly Cache) ne prend plus en charge la visionneuse du plug-in du shell.	Aucune.

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 du 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é changée pour correspondre au paramètre `pStringLengthOffset`. Les deux paramètres pointent désormais vers l’emplacement de décalage de la longueur de la chaîne. La longueur du tampon a été supprimée de la représentation de la classe de chaîne.	Supprimez toute dépendance sur la longueur du tampon.
Débogage juste-à-temps	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. Ce changement a les conséquences suivantes : * 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 quand le débogueur ne peut pas démarrer ou quand 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 plateforme	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 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 signale ces erreurs pour que vous puissiez les corriger. Si vous avez des 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 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	Aucune.

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