Changements importants dans ASP.NET 4

Article
06/16/2023

Ce document décrit les modifications apportées à la version 4 du .NET Framework qui peuvent potentiellement affecter les applications qui ont été créées à l’aide de versions antérieures, notamment les versions bêta 1 et bêta 2 ASP.NET 4.

Télécharger ce livre blanc

Contenu

Paramètre ControlRenderingCompatibilityVersion dans le fichier Web.config
Modifications du clientIDMode
HtmlEncode et UrlEncode Now Encodent des guillemets uniques
ASP.NET Page (.aspx) L’analyseur est plus strict
Fichiers de définition de navigateur mis à jour
System.Web.Mobile.dll supprimé du fichier de configuration web racine

L’algorithme de hachage par défaut est maintenant HMACSHA256
Erreurs de configuration liées à la nouvelle configuration racine ASP.NET 4
ASP.NET 4 applications enfants ne parviennent pas à démarrer lorsque les applications ASP.NET 2.0 ou ASP.NET 3.5 échouent
ASP.NET 4 sites web ne démarrent pas sur les ordinateurs où SharePoint est installé
La propriété HttpRequest.FilePath n’inclut plus les valeurs PathInfo
applications ASP.NET 2.0 peuvent générer des erreurs HttpException qui référencent eurl.axd
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
Modifications apportées à l’implémentation de la sécurité d’accès au code ASP.NET (CAS)
MembershipUser et d’autres types dans l’espace de noms System.Web.Security ont été déplacés
Modifications apportées à la mise en cache de sortie pour varier * En-tête HTTP
Les types System.Web.Security pour Passport sont obsolètes
La propriété MenuItem.PopOutImageUrl ne parvient pas à restituer une image dans ASP.NET 4
Menu.StaticPopOutImageUrl et Menu.DynamicPopOutImageUrl Ne parviennent pas à restituer les images lorsque les chemins contiennent des barres obliques inverses
Avertissement

Paramètre ControlRenderingCompatibilityVersion dans le fichier Web.config

ASP.NET contrôles ont été modifiés dans .NET Framework version 4 afin de vous permettre de spécifier plus précisément la façon dont ils affichent le balisage. Dans les versions précédentes du .NET Framework, certains contrôles émettaient du balisage que vous n’aviez aucun moyen de désactiver. Par défaut, ASP.NET 4, ce type de balisage n’est plus généré.

Si vous utilisez Visual Studio 2010 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 qui préserve le Web.config rendu hérité. Toutefois, si vous mettez à niveau une application en changeant le pool d’applications dans IIS pour cibler le .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 dans le Web.config fichier :

<pages controlRenderingCompatibilityVersion="3.5" />

Les principales modifications de rendu apportées par le nouveau comportement sont les suivantes :

Les contrôles Image et ImageButton ne rendent plus d’attribut border="0" .
La classe BaseValidator et les contrôles de validation qui en dérivent ne rendent plus le 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 utilisateur (par exemple, le contrôle Label ) ne rendent 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).

Modifications du clientIDMode

Le 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 précédentes de ASP.NET, le comportement par défaut était équivalent au paramètre AutoID de ClientIDMode. Toutefois, le paramètre par défaut est désormais prévisible.

Si vous utilisez Visual Studio 2010 pour mettre à niveau votre application à partir de ASP.NET 2.0 ou ASP.NET 3.5, l’outil ajoute automatiquement un paramètre au Web.config fichier qui préserve le comportement des versions antérieures du .NET Framework. Toutefois, si vous mettez à niveau une application en changeant le pool d’applications dans IIS pour cibler le .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 dans le Web.config fichier :

<pages clientIDMode="AutoID" />

HtmlEncode et UrlEncode Now Encodent des guillemets uniques

Dans ASP.NET 4, les méthodes HtmlEncode et UrlEncode des classes HttpUtility et HttpServerUtility ont été mises à jour pour encoder le caractère de guillemet unique (') comme suit :

La méthode HtmlEncode encode les instances du guillemet unique en ' .
La méthode UrlEncode encode les instances du guillemet unique sous la forme %27.

ASP.NET Page (.aspx) L’analyseur est plus strict

L’analyseur de page pour ASP.NET pages (.aspx fichiers) et les contrôles utilisateur (.ascx fichiers) est plus strict dans ASP.NET 4 et rejette d’autres instances de balisage non valides. Par exemple, les deux extraits de code suivants sont correctement analysés dans les versions antérieures de ASP.NET, mais déclenchent désormais des erreurs d’analyseur dans ASP.NET 4.

<asp:HiddenField runat="server" ID="SomeControl" Value="sampleValue"  ; />

Notez le point-virgule non valide à la fin de la balise HiddenField .

<asp:LinkButton runat="server" ID="SomeControl" onclick="someControlClicked"
      style="display:inline;  CssClass="searchLink"  />

Notez l’attribut de style non fermé qui s’exécute dans l’attribut CssClass .

Fichiers de définition de navigateur mis à jour

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. Par exemple, si le App_Browsers dossier contient une définition de navigateur qui hérite de la définition de navigateur IE2, vous recevez le message d’erreur de configuration suivant :

Impossible de trouver l’élément de navigateur ou de passerelle avec l’ID « IE2 ».

Notes

L’objet HttpBrowserCapabilities (qui est exposé par la propriété Request.Browser de la page) est piloté par les fichiers de définitions du navigateur. Par conséquent, les informations retournées par l’accès à 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.

Vous pouvez revenir aux anciens fichiers de définition de navigateur en copiant les fichiers de définition de navigateur à partir du dossier suivant :

Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers

Copiez les fichiers dans le dossier correspondant \CONFIG\Browsers pour ASP.NET 4. Après avoir copié les fichiers, exécutez l’outil en ligne de commande Aspnet_regbrowsers.exe.

System.Web.Mobile.dll supprimé du fichier de configuration web racine

Dans les versions précédentes de ASP.NET, une référence à l’assembly System.Web.Mobile.dll était incluse dans le fichier racine Web.config dans la section assemblys sous . Pour améliorer les performances, la référence à cet assembly a été supprimée.

L’assembly System.Web.Mobile.dll est inclus dans ASP.NET 4, mais il est déconseillé. Si vous souhaitez utiliser des types de l’assembly System.Web.Mobile.dll, ajoutez une référence à cet assembly dans le fichier racine Web.config ou dans un fichier d’application Web.config . Par exemple, si vous souhaitez utiliser l’un des contrôles mobiles (déconseillés) ASP.NET, vous devez ajouter une référence à l’assembly System.Web.Mobile.dll au Web.config fichier.

validation de requête ASP.NET

La fonctionnalité de validation des requêtes dans ASP.NET fournit un certain niveau de protection par défaut contre les attaques par script de site (XSS). Dans les versions précédentes de ASP.NET, la validation des demandes était activée par défaut. Toutefois, elle ne s’appliquait qu’à ASP.NET pages (.aspx fichiers et leurs fichiers de classe) et uniquement lorsque ces pages s’exécutaient.

Dans ASP.NET 4, par défaut, la validation des demandes est activée pour toutes les requêtes, car elle est activée avant la phase BeginRequest d’une requête HTTP. Par conséquent, la validation des demandes s’applique aux demandes pour toutes les ressources ASP.NET, et pas seulement aux demandes de page .aspx. Cela inclut les requêtes telles que les appels de service web et les gestionnaires HTTP personnalisés. La validation de requête est également active lorsque des modules HTTP personnalisés lisent le contenu d’une requête HTTP.

Par conséquent, des erreurs de validation de demande peuvent maintenant se produire pour les demandes qui n’ont pas déclenché d’erreurs auparavant. Pour rétablir le comportement de la fonctionnalité de validation des requêtes ASP.NET 2.0, ajoutez le paramètre suivant dans le Web.config fichier :

<httpRuntime requestValidationMode="2.0" />

Toutefois, nous vous recommandons d’analyser toutes les erreurs de validation de requête pour déterminer si les gestionnaires, modules ou autres codes personnalisés existants accèdent à des entrées HTTP potentiellement dangereuses qui pourraient être des vecteurs d’attaque XSS.

L’algorithme de hachage par défaut est maintenant HMACSHA256

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 désormais l’algorithme HMACSHA256 pour les opérations de hachage sur les cookies et l’état d’affichage. Les versions antérieures de ASP.NET utilisaient l’ancien algorithme HMACSHA1.

Vos applications peuvent être affectées si vous exécutez des environnements mixtes ASP.NET 2.0/ASP.NET 4 où les données telles que les cookies d’authentification par formulaire doivent fonctionner across.NET Framework. Pour configurer une application web ASP.NET 4 afin d’utiliser l’ancien algorithme HMACSHA1, ajoutez le paramètre suivant dans le Web.config fichier :

<machineKey validation="SHA1" />

Les fichiers de configuration racine (le machine.config fichier et le fichier racine Web.config ) du .NET Framework 4 (et donc ASP.NET 4) ont été mis à jour pour inclure la plupart des informations de configuration réutilisables qui se trouvaient dans ASP.NET 3.5 dans les fichiers d’application Web.config . 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 IIS 7 et IIS 7.5 peut entraîner des erreurs de configuration ASP.NET ou IIS.

Nous vous recommandons de mettre à niveau ASP.NET applications 3.5 vers ASP.NET 4 à l’aide des outils de mise à niveau de projet dans Visual Studio 2010, si cela est possible. Visual Studio 2010 modifie automatiquement le fichier de l’application ASP.NET 3.5 pour qu’il Web.config contienne les paramètres appropriés pour ASP.NET 4.

Toutefois, il s’agit d’un scénario pris en charge pour exécuter ASP.NET applications 3.5 à l’aide du .NET Framework 4 sans recompilation. Dans ce cas, vous devrez peut-être modifier manuellement le fichier de Web.config l’application avant d’exécuter l’application sous .NET Framework 4 et sous IIS 7 ou IIS 7.5.

Les deux sections suivantes décrivent les modifications que vous devrez peut-être apporter pour différentes combinaisons de logiciels.

Windows Vista SP1 ou Windows Server 2008 SP1, où ni le correctif logiciel KB958854 ni SP2 ne sont installés. Dans cette configuration, le système de configuration IIS 7 fusionne incorrectement la configuration managée d’une application en comparant le fichier au niveau Web.config de l’application aux fichiers ASP.NET 2.0 machine.config . Pour cette raison, les fichiers au niveau Web.config de l’application du .NET Framework 3.5 ou version ultérieure doivent avoir une définition de section de configuration system.web.extensions (l’élément) pour ne pas provoquer d’échec de validation IIS 7.

Toutefois, les entrées de fichier modifiées manuellement au niveau Web.config de l’application qui ne correspondent pas précisément aux définitions de section de configuration réutilisables d’origine introduites avec Visual Studio 2008 entraînent des erreurs de configuration ASP.NET. (Les entrées de configuration par défaut générées par Visual Studio 2008 fonctionnent correctement.) Un problème courant est que les fichiers modifiés Web.config manuellement omettez les attributs de configuration allowDefinition et requirePermission qui se trouvent dans différentes définitions de section de configuration. Cela entraîne une incompatibilité entre la section de configuration abrégée dans les fichiers au niveau Web.config de l’application et la définition complète dans le fichier ASP.NET 4 machine.config . Par conséquent, au moment de l’exécution, le système de configuration ASP.NET 4 lève une erreur de configuration.

Windows Vista SP2, Windows Server 2008 SP2, Windows 7, Windows Server 2008 R2, ainsi que Windows Vista SP1 et Windows Server 2008 SP1 où le correctif logiciel KB958854 est installé.

Dans ce scénario, le système de configuration native IIS 7 et IIS 7.5 retourne une erreur de configuration, car il effectue une comparaison de texte sur l’attribut type défini pour un gestionnaire de section de configuration managée. Étant donné que tous les Web.config fichiers générés par Visual Studio 2008 et Visual Studio 2008 SP1 ont « 3.5 » dans la chaîne de type pour les gestionnaires de section de configuration system.web.extensions (et associés), et comme le fichier ASP.NET 4 machine.config contient « 4.0 » dans l’attribut type pour les mêmes gestionnaires de section de configuration, les applications générées dans Visual Studio 2008 ou Visual Studio 2008 SP1 échouent toujours à la validation de configuration dans IIS 7 et IIS 7.5.

Résolution de ces problèmes

La solution de contournement pour le premier scénario consiste à mettre à jour le fichier au niveau Web.config de l’application en incluant le texte de configuration réutilisable d’un Web.config fichier généré automatiquement par Visual Studio 2008.

Une autre solution de contournement pour le premier scénario consiste à installer Le Service Pack 2 pour Vista ou Windows Server 2008 sur votre ordinateur afin de corriger le comportement incorrect de configuration-fusion du système de configuration IIS. Toutefois, après avoir effectué l’une de ces actions, votre application rencontrera probablement une erreur de configuration en raison du problème décrit pour le deuxième scénario.

La solution de contournement pour le deuxième scénario consiste à supprimer ou à commenter toutes les définitions de section de configuration system.web.extensions et les définitions de groupe de sections de configuration du fichier au niveau Web.config de l’application. Ces définitions se trouvent généralement en haut du fichier au niveau Web.config de l’application et peuvent être identifiées par l’élément configSections et ses enfants.

Pour les deux scénarios, il est recommandé de supprimer manuellement la section system.codedom , bien que cela ne soit pas obligatoire.

ASP.NET 4 applications enfants ne parviennent pas à démarrer lorsque les applications ASP.NET 2.0 ou ASP.NET 3.5 ne parviennent pas à démarrer

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’exemple suivant montre une structure de répertoires pour une application affectée.

/parentwebapp (configuré pour utiliser ASP.NET 2.0 ou ASP.NET 3.5)
/childwebapp (configuré pour utiliser ASP.NET 4)

L’application dans le childwebapp dossier ne parvient pas à démarrer sur IIS 7 ou IIS 7.5 et signale une erreur de configuration. Le texte d’erreur inclut un message similaire au suivant :

The requested page cannot be accessed because the related configuration data for the page is invalid.
The configuration section 'configSections' cannot be read because it is missing a section declaration.

Sur IIS 6, l’application dans le childwebapp dossier ne parvient pas non plus à démarrer, mais elle signale une autre erreur. Par exemple, le texte d’erreur peut indiquer ce qui suit :

The value for the 'compilerVersion' attribute in the provider options must be 'v4.0' or later if you are compiling for version 4.0 or later of the .NET Framework. To compile this Web application for version 3.5 or earlier of the .NET Framework, remove the 'targetFramework' attribute from the element of the Web.config file

Ces scénarios se produisent parce que les informations de configuration de l’application parente dans le parentwebapp dossier font partie de la hiérarchie des informations de configuration qui détermine les paramètres de configuration fusionnés finaux utilisés par l’application web enfant dans le childwebapp dossier. Selon que l’application web ASP.NET 4 s’exécute sur IIS 7 (ou IIS 7.5) ou sur IIS 6, le système de configuration IIS ou le système de compilation ASP.NET 4 retourne une erreur.

Les étapes que vous devez suivre pour résoudre ce problème et pour que l’application enfant ASP.NET 4 fonctionne selon que l’application ASP.NET 4 s’exécute sur IIS 6 ou SUR IIS 7 (ou IIS 7.5).

Étape 1 (IIS 7 ou IIS 7.5 uniquement)

Cette étape est nécessaire uniquement sur les systèmes d’exploitation qui exécutent IIS 7 ou IIS 7.5, notamment Windows Vista, Windows Server 2008, Windows 7 et Windows Server 2008 R2.

Déplacez la définition configSections dans le Web.config fichier de l’application parente (l’application qui exécute ASP.NET 2.0 ou ASP.NET 3.5) dans le fichier racine Web.config pour the.NET Framework 2.0. Le système de configuration native IIS 7 et IIS 7.5 analyse l’élément configSections lorsqu’il fusionne la hiérarchie des fichiers de configuration. Le déplacement de la définition configSections du fichier de Web.config l’application web parente vers le fichier racine Web.config masque efficacement l’élément du processus de fusion de configuration qui se produit pour l’application enfant ASP.NET 4.

Sur un système d’exploitation 32 bits ou pour des pools d’applications 32 bits, le fichier racine Web.config pour ASP.NET 2.0 et ASP.NET 3.5 se trouve normalement dans le dossier suivant :

C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG

Sur un système d’exploitation 64 bits ou pour des pools d’applications 64 bits, le fichier racine Web.config pour ASP.NET 2.0 et ASP.NET 3.5 se trouve normalement dans le dossier suivant :

C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG

Si vous exécutez des applications Web 32 bits et 64 bits sur un ordinateur 64 bits, vous devez déplacer l’élément configSections vers le haut dans les fichiers racines Web.config pour les systèmes 32 bits et 64 bits.

Lorsque vous placez l’élément configSections dans le fichier racine Web.config , collez la section immédiatement après l’élément de configuration . L’exemple suivant montre à quoi doit ressembler la partie supérieure du fichier racine Web.config lorsque vous avez terminé de déplacer les éléments.

Notes

Dans l’exemple suivant, les lignes ont été encapsulées pour plus de lisibilité.

<?xml version="1.0" encoding="utf-8"?>
<!-- The root web configuration file -->
<configuration>
  <configSections>
    <sectionGroup name="system.web.extensions"
        type="System.Web.Configuration.SystemWebExtensionsSectionGroup, 
      System.Web.Extensions, Version=3.5.0.0, Culture=neutral,  
      PublicKeyToken=31BF3856AD364E35">

      <sectionGroup name="scripting"
        type="System.Web.Configuration.ScriptingSectionGroup, 
        System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
        PublicKeyToken=31BF3856AD364E35">

        <section name="scriptResourceHandler"
          type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, 
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35" requirePermission="false"
          allowDefinition="MachineToApplication" />

        <sectionGroup name="webServices"
          type="System.Web.Configuration.ScriptingWebServicesSectionGroup,
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35">

          <section name="jsonSerialization"
            type="System.Web.Configuration.ScriptingJsonSerializationSection, 
            System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
            PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="Everywhere" />

          <section name="profileService"
            type="System.Web.Configuration.ScriptingProfileServiceSection, 
            System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
            PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="MachineToApplication" />
          <section name="authenticationService"
            type="System.Web.Configuration.ScriptingAuthenticationServiceSection, 
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="MachineToApplication" />

          <section name="roleService"
            type="System.Web.Configuration.ScriptingRoleServiceSection, 
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="MachineToApplication" />

        </sectionGroup>
      </sectionGroup>
    </sectionGroup>
  </configSections>

Étape 2 (toutes les versions d’IIS)

Cette étape est requise si l’application web enfant ASP.NET 4 s’exécute sur IIS 6 ou IIS 7 (ou IIS 7.5).

Dans le Web.config fichier de l’application web parente qui exécute ASP.NET 2 ou ASP.NET 3.5, ajoutez une balise d’emplacement qui spécifie explicitement (pour les systèmes de configuration IIS et ASP.NET) que les entrées de configuration s’appliquent uniquement à l’application web parente. L’exemple suivant montre la syntaxe de l’élément location à ajouter :

<location path="" inheritInChildApplications="false" >
  <!-- Additional settings -->
</location>

L’exemple suivant montre comment la balise d’emplacement est utilisée pour encapsuler toutes les sections de configuration en commençant par la section appSettings et se terminant par la section system.webServer .

<location path="" inheritInChildApplications="false" >
  <appSettings />
  <connectionStrings />
  <system.web>
    <!-- Removed for brevity -->
  </system.web>
  <system.codedom>
    <!-- Removed for brevity -->
  </system.codedom>
  <system.webServer>
    <!-- Removed for brevity -->
</system.webServer>
</location>

Lorsque vous avez terminé les étapes 1 et 2, les applications web enfants ASP.NET 4 démarrent sans erreurs.

ASP.NET 4 sites web ne parviennent pas à démarrer sur les ordinateurs sur lesquels SharePoint est installé

Les serveurs Web qui exécutent SharePoint ont un Web.config fichier déployé à la racine d’un site Web SharePoint (par exemple, c:\inetpub\wwwroot\web.config pour site web par défaut). Dans ce Web.config fichier, SharePoint définit un niveau de confiance partielle personnalisé nommé WSS_Minimal.

Si vous essayez d’exécuter un site Web ASP.NET 4 déployé en tant qu’enfant de ce type de site Web SharePoint, l’erreur suivante s’affiche :

Could not find permission set named 'ASP.NET'.

Cette erreur se produit parce que l’infrastructure de sécurité d’accès (CAS) ASP.NET 4 recherche un jeu d’autorisations nommé ASP.NET. Toutefois, le fichier de configuration de confiance partielle référencé par WSS_Minimal ne contient aucun jeu d’autorisations portant ce nom.

Actuellement, il n’existe pas de version de SharePoint compatible avec ASP.NET. Par conséquent, vous ne devez pas essayer d’exécuter un site Web ASP.NET 4 en tant que site enfant sous sites Web SharePoint.

La propriété HttpRequest.FilePath n’inclut plus de valeurs PathInfo

Les versions précédentes de ASP.NET incluaient une valeur PathInfo dans la valeur retournée par diverses propriétés liées au chemin d’accès de fichier, notamment HttpRequest.FilePath, HttpRequest.AppRelativeCurrentExecutionFilePath et HttpRequest.CurrentExecutionFilePath. ASP.NET 4 n’inclut plus la valeur PathInfo dans les valeurs de retour de ces propriétés. Au lieu de cela, 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 de ASP.NET, les propriétés HttpRequest ont les valeurs suivantes :

HttpRequest.FilePath : /testapp/Action.mvc/SomeAction

HttpRequest.PathInfo : (vide)

Dans ASP.NET 4, les propriétés HttpRequest ont plutôt les valeurs suivantes :

HttpRequest.FilePath : /testapp/Action.mvc

HttpRequest.PathInfo : SomeAction

ASP.NET applications 2.0 peuvent générer des erreurs HttpException qui référencent eurl.axd

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) risquent de générer des erreurs comme la suivante :

System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.

Cette erreur se produit car quand ASP.NET détecte qu’un site Web est configuré pour utiliser ASP.NET 4, un composant natif de ASP.NET 4 transmet une URL sans extension à la partie gérée de ASP.NET pour un traitement ultérieur. Toutefois, si les répertoires virtuels qui se trouvent sous un site Web ASP.NET 4 sont configurés pour utiliser ASP.NET 2.0, le traitement de l’URL sans extension de cette façon entraîne une URL modifiée qui contient la chaîne « eurl.axd ». Cette URL modifiée est ensuite envoyée à l’application ASP.NET 2.0. ASP.NET 2.0 ne peut pas reconnaître le format « eurl.axd ». Par conséquent, ASP.NET 2.0 tente de trouver un fichier nommé eurl.axd et de l’exécuter. Étant donné qu’il n’existe aucun fichier de ce type, la requête échoue avec une exception HttpException .

Vous pouvez contourner ce problème à l’aide de l’une des options suivantes.

Option 1 :

Si ASP.NET 4 n’est pas nécessaire pour exécuter le site Web, remapper le site pour utiliser ASP.NET 2.0 à la place.

Option 2 :

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.

Option 3

S’il n’est pas pratique de remapper le site Web sur ASP.NET 2.0 ou de modifier l’emplacement d’un répertoire virtuel, désactivez explicitement le traitement d’URL sans extension dans ASP.NET 4. Suivez la procédure suivante :

Dans le Registre Windows, ouvrez le nœud suivant :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0

Créez une valeur DWORD nommée EnableExtensionlessUrls.
Définissez EnableExtensionlessUrls sur 0. Cela désactive le comportement d’URL sans extension.
Enregistrez la valeur du Registre et fermez l’éditeur du Registre.
Exécutez l’outil en ligne de commande iisreset , ce qui permet à IIS de lire la nouvelle valeur de Registre.

Notes

La définition de EnableExtensionlessUrls sur 1 active le comportement d’URL sans extension. Il s’agit du paramètre par défaut si aucune valeur n’est spécifiée.

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

ASP.NET 4 inclut des modifications qui modifient le rendu de l’attribut d’action de l’élément de formulaire HTML lorsqu’une URL sans extension est résolue en document par défaut. Un exemple d’URL sans extension résolvant un document par défaut serait http://contoso.com/, ce qui entraînerait une demande à http://contoso.com/Default.aspx.

ASP.NET 4 affiche désormais la valeur de l’attribut action de l’élément de formulaire HTML sous la forme d’une chaîne vide lorsqu’une requête est effectuée vers une URL sans extension sur laquelle un document par défaut est mappé. Par exemple, dans les versions antérieures de ASP.NET, une demande à http://contoso.com entraînerait une demande à Default.aspx. Dans ce document, la balise de formulaire ouvrante est 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. Toutefois, ASP.NET affiche maintenant la balise de formulaire d’ouverture HTML comme dans l’exemple suivant :

<form action="" />

Cette différence dans le rendu de l’attribut d’action peut entraîner des modifications subtiles dans la façon dont un billet de formulaire est traité par IIS et ASP.NET. Lorsque l’attribut d’action est une chaîne vide, l’objet IIS DefaultDocumentModule crée une requête enfant à Default.aspx. Dans la plupart des conditions, cette requête enfant est transparente pour le code de l’application et la page s’exécute Default.aspx 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 adressée à un Default.aspx document génère une erreur ou un comportement inattendu :

Une page .aspx est envoyée au navigateur avec l’attribut d’action de l’élément de formulaire défini sur « ».
Le formulaire est renvoyé à ASP.NET.
Un module HTTP managé lit une partie du corps de l’entité. Par exemple, un module lit 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 DefaultDocumentModule IIS finit par s’exécuter et crée une requête enfant pour le Default.aspx document. 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 requête enfant, le gestionnaire de fichiers s’exécute .aspx pendant la phase gestionnaire-exécution.
Étant donné qu’il n’y a pas de corps d’entité, il n’y a pas de variables de formulaire ni d’état d’affichage. Par conséquent, aucune information n’est disponible pour que le gestionnaire de pages .aspx détermine quel événement (le cas échéant) est censé être déclenché. Par conséquent, aucun des gestionnaires d’événements de publication pour la page .aspx concernée ne s’exécute.

Vous pouvez contourner ce comportement des manières suivantes :

Identifiez le module HTTP qui accède au corps de l’entité de la demande lors des demandes de document par défaut et déterminez s’il peut être configuré pour s’exécuter uniquement pour les requêtes managées. En mode intégré pour IIS 7 et IIS 7.5, les modules HTTP peuvent être marqués pour s’exécuter uniquement pour les requêtes managées en ajoutant l’attribut suivant à l’entrée system.webServer/modules du module :
precondition="managedHandler"
Ce paramètre désactive le module pour les demandes que IIS 7 et IIS 7.5 déterminent comme n’étant pas des requêtes gérées. Pour les demandes de documents par défaut, la première demande est envoyée à une URL sans extension. Par conséquent, IIS n’exécute pas de modules managés marqués avec une condition préalable de gestionnaire managé pendant le traitement de la demande initiale. Par conséquent, les modules managés ne lisent pas accidentellement le corps de l’entité et, par conséquent, le corps de l’entité est toujours disponible et est transmis à la requête enfant et au document par défaut.
Si les modules HTTP problématiques doivent s’exécuter pour toutes les requêtes (pour les fichiers statiques, pour les URL sans extension qui sont résolues en objet DefaultDocumentModule , pour les requêtes managées, etc.), modifiez les pages .aspx affectées en définissant explicitement la propriété Action du contrôle System.Web.UI.HtmlControls.HtmlForm de la page sur une chaîne non vide. Par exemple, si le document par défaut est Default.aspx, modifiez le code de la page pour définir explicitement la propriété Action du contrôle HtmlForm sur « Default.aspx ».

Modifications apportées à l’implémentation ASP.NET Code Access Security (CAS)

ASP.NET 2.0 et, par extension, les fonctionnalités ASP.NET qui ont été ajoutées dans la version 3.5, utilisent le modèle de sécurité d’accès du code (CAS) .NET Framework 1.1 et 2.0. Toutefois, l’implémentation de CAS dans ASP.NET 4 a été considérablement revue. 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 (GAC) peuvent échouer avec diverses exceptions de sécurité. Les applications à confiance partielle qui s’appuient sur des modifications importantes de la stratégie CAS de l’ordinateur peuvent également échouer avec des exceptions de sécurité.

Vous pouvez rétablir la confiance partielle ASP.NET 4 applications au comportement de ASP.NET 1.1 et 2.0 à l’aide du nouvel attribut legacyCasModel dans l’élément de configuration trust , comme illustré dans l’exemple suivant :

<trust level= "Medium" legacyCasModel="true" />

Lorsque vous revenez au modèle CAS hérité, les anciens comportements CAS suivants sont activés :

La stratégie CAS de l’ordinateur est respectée.
Plusieurs jeux d’autorisations différents dans un même domaine d’application sont autorisés.
Les assertions d’autorisation explicites ne sont pas requises pour les assemblys dans le GAC qui sont appelés lorsque seul ASP.NET ou un autre code .NET Framework se trouve sur la pile.

Un scénario ne peut pas être rétabli dans le .NET Framework 4 : les applications non web à confiance partielle ne peuvent plus appeler certaines API dans System.Web.dll et System.Web.Extensions.dll. Dans les versions précédentes du .NET Framework, il était possible pour les applications non-Web d’obtenir des autorisations AspNetHostingPermission explicitement. Ces applications peuvent ensuite utiliser System.Web.HttpUtility, les types dans les espaces de noms System.Web.ClientServices.* et les types liés à l’appartenance, aux rôles et aux profils. L’appel de ces types à partir d’applications de confiance partielle non web n’est plus pris en charge dans .NET Framework 4.

Notes

Les fonctionnalités HtmlEncode et HtmlDecode de la classe System.Web.HttpUtility ont été déplacées vers la nouvelle classe .NET Framework 4 System.Net.WebUtility . S’il s’agissait de la seule fonctionnalité ASP.NET utilisée, modifiez le code de l’application pour utiliser la nouvelle classe WebUtility à la place.

Voici un résumé général des modifications apportées à l’implémentation cas par défaut dans ASP.NET 4 :

ASP.NET domaines d’application sont désormais des domaines d’application homogènes. Seuls les jeux d’octroi de confiance partielle et de confiance totale sont disponibles dans un domaine d’application.
ASP.NET jeux d’octrois de confiance partielle sont indépendants de toute stratégie CAS au niveau de l’entreprise, de l’ordinateur ou de l’utilisateur.
ASP.NET assemblys fournis dans les versions 3.5 et 3.5 SP1 ont été convertis pour utiliser le modèle de transparence .NET Framework 4.
L’utilisation de l’attribut aspNetHostingPermission ASP.NET a été considérablement réduite. La plupart des instances de cet attribut ont été supprimées des API ASP.NET publiques.
Les assemblys compilés dynamiquement qui sont créés par ASP.NET fournisseurs de build ont été mis à jour pour marquer explicitement les assemblys comme transparents.
Tous les assemblys ASP.NET sont désormais marqués de telle sorte que l’attribut APTCA soit respecté uniquement dans les environnements d’hébergement web. Les environnements d’hébergement non web partiellement approuvés comme ClickOnce ne pourront pas appeler ASP.NET assemblys.

Pour plus d’informations sur le nouveau modèle de sécurité d’accès au code ASP.NET 4, consultez Utilisation de la sécurité d’accès au code dans les applications ASP.NET sur le site web MSDN.

MembershipUser et d’autres types dans l’espace de noms System.Web.Security ont été déplacés

Certains types utilisés dans ASP.NET appartenance ont été déplacés de System.Web.dll vers le nouvel 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 projets de site Web ne rencontrent pas de problèmes en raison du déplacement de ces types, car System.Web.ApplicationServices.dll a été ajouté à la liste des assemblys référencés qui est utilisé par défaut par le système de compilation ASP.NET. Si vous mettez à niveau un projet de site Web créé à l’aide d’une version antérieure de ASP.NET vers ASP.NET 4 en l’ouvrant dans Visual Studio 2010, le projet se compile sans erreur.

De même, si vous mettez à niveau un projet d’application web créé dans une version antérieure de ASP.NET vers ASP.NET 4 en l’ouvrant dans Visual Studio 2010, le processus de mise à niveau ajoute une référence à System.Web.ApplicationServices.dll au projet. Par conséquent, les projets d’application web mis à niveau se compilent également sans erreurs.

Les fichiers compilés (binaires) créés à l’aide de versions antérieures de ASP.NET s’exécutent également sans erreur sur ASP.NET 4, même si les types d’appartenance ont été déplacés vers un autre assembly. Des informations de transfert de type ont été ajoutées à la version ASP.NET 4 de System.Web.dll qui achemine automatiquement les références d’exécution pour ces types vers le nouvel emplacement des types.

Toutefois, les bibliothèques de classes qui utilisent des types d’appartenance spécifiques et qui ont été mises à niveau à partir de versions antérieures de ASP.NET ne pourront pas être compilées lorsqu’elles sont utilisées dans un projet ASP.NET 4. Par exemple, un projet de bibliothèque de classes peut ne pas être compilé et signaler une erreur telle que la suivante :

The type 'System.Web.Security.MembershipUser' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Web.ApplicationServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
The type name 'MembershipUser' could not be found. This type has been forwarded to assembly 'System.Web.ApplicationServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Consider adding a reference to that assembly.

Vous pouvez contourner ce problème en ajoutant une référence dans votre projet de bibliothèque de classes à System.Web.ApplicationServices.dll.

La liste suivante montre les types System.Web.Security qui ont été déplacés de System.Web.dll à System.Web.ApplicationServices.dll :

System.Web.Security.MembershipCreateStatus
System.Web.Security.Membership.CreateUserException
System.Web.Security.MembershipPasswordException
System.Web.Security.MembershipPasswordFormat
System.Web.Security.MembershipProvider
System.Web.Security.MembershipProviderCollection
System.Web.Security.MembershipUser
System.Web.Security.MembershipUserCollection
System.Web.Security.MembershipValidatePasswordEventHandler
System.Web.Security.ValidatePasswordEventArgs
System.Web.Security.RoleProvider
System.Web.Configuration.MembershipPasswordCompatibilityMode

Modifications de la mise en cache de sortie pour varier * en-tête HTTP

Dans ASP.NET 1.0, un bogue a provoqué l’émission d’un Vary:* en-tête HTTP dans la réponse des pages mises en cache spécifiées Location="ServerAndClient" comme paramètre de sortie-cache. Les navigateurs clients ne mettaient donc jamais en cache la page localement.

Dans ASP.NET 1.1, la méthode System.Web.HttpCachePolicy.SetOmitVaryStar a été ajoutée, que vous pouvez appeler pour supprimer l’en-tête Vary:* . Cette méthode a été choisie, car la modification de l’en-tête HTTP émis a été considérée comme une modification potentiellement cassant à l’époque. Toutefois, les développeurs ont été confondus par le comportement dans ASP.NET, et les rapports de bogues suggèrent que les développeurs ne sont pas conscients du comportement setOmitVaryStar existant.

Dans ASP.NET 4, la décision a été prise de résoudre le problème racine. L’en-tête Vary:* HTTP n’est plus émis à partir des réponses qui spécifient la directive suivante :

<%@OutputCache Location="ServerAndClient" %>

Par conséquent, SetOmitVaryStar n’est plus nécessaire pour supprimer l’en-tête Vary:* .

Dans les applications qui spécifient Location="ServerAndClient" dans la directive @ OutputCache sur une page, vous voyez maintenant le comportement impliqué par le nom de la valeur de l’attribut Location , c’est-à-dire que les pages peuvent être mises en cache dans le navigateur sans que vous ayez besoin d’appeler la méthode SetOmitVaryStar .

Si les pages de votre application doivent émettre Vary:*, appelez la méthode AppendHeader , comme dans l’exemple suivant :

HttpResponse.AppendHeader("Vary","*");

Vous pouvez également modifier la valeur de l’attribut Emplacement de mise en cache de sortie en « Serveur ».

Les types System.Web.Security pour Passport sont obsolètes

La prise en charge de Passport intégrée à ASP.NET 2.0 est obsolète et non prise en charge depuis quelques années en raison des modifications apportées à Passport (maintenant LiveID). Par conséquent, les cinq types liés à Passport dans System.Web.Security sont maintenant marqués avec l’attribut ObsoleteAttribute .

La propriété MenuItem.PopOutImageUrl ne parvient pas à restituer une image dans ASP.NET 4

Dans ASP.NET 3.5, la propriété MenuItem.PopOutImageUrl vous permet de spécifier l’URL d’une image affichée dans un élément de menu pour indiquer que l’élément de menu a un sous-menu dynamique. L’exemple suivant montre comment spécifier cette propriété dans le balisage dans ASP.NET 3.5.

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical" 
    target="_blank"  
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        PopOutImageUrl="~/Images/Popout.gif"   
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          PopOutImageUrl="~/Images/Popout.gif"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

À la suite d’une modification de conception dans ASP.NET 4, aucune sortie n’est rendue pour popOutImageUrl si la propriété est définie pour la classe MenuItem . Au lieu de cela, vous devez spécifier une URL d’image directement dans le contrôle Menu à l’aide de la propriété StaticPopOutImageUrl ou de la propriété DynamicPopOutImageUrl . Lorsque vous utilisez un menu statique, la propriété Menu.StaticPopOutImageUrl spécifie l’URL d’une image qui s’affiche afin d’indiquer que l’élément de menu statique comporte un sous-menu, comme illustré dans l’exemple suivant :

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical" 
    target="_blank" 
    StaticPopOutImageTextFormatString="More..."
    StaticPopOutImageUrl="Images/Popout.gif"   
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

Si vous utilisez un menu dynamique, vous utilisez la propriété Menu.DynamicPopOutImageUrl pour spécifier l’URL d’une image qui indique qu’un élément de menu dynamique a un sous-menu. L’exemple suivant est similaire au précédent, mais montre comment définir la propriété DynamicPopOutImageUrl pour un menu dynamique.

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical" 
    target="_blank" 
    DynamicPopOutImageTextFormatString="More..."
    DynamicPopOutImageUrl="Images/Popout.gif" 
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

Si la propriété Menu.DynamicPopOutImageUrl n’est pas définie et que la propriété Menu.DynamicEnableDefaultPopOutImage a la valeur false, aucune image n’est affichée. De même, si la propriété StaticPopOutImageUrl n’est pas définie et que la propriété StaticEnableDefaultPopOutImage a la valeur false, aucune image n’est affichée.

Lorsque vous définissez les chemins d’accès pour ces propriétés, utilisez une barre oblique (/) au lieu d’une barre oblique inverse (). Pour plus d’informations, consultez Menu.StaticPopOutImageUrl et Menu.DynamicPopOutImageUrl Ne parviennent pas à restituer les images lorsque les chemins contiennent des barres obliques inverses ailleurs dans ce document.

Menu.StaticPopOutImageUrl et Menu.DynamicPopOutImageUrl Ne parviennent pas à restituer les images lorsque les chemins contiennent des barres obliques inverses

Dans ASP.NET 4, les images que vous spécifiez à l’aide des propriétés Menu.StaticPopOutImageUrl et Menu.DynamicPopOutImageUrl ne seront pas affichées si le chemin contient des barres obliques inverses (). Il s’agit d’une modification par exemple des versions antérieures de ASP.NET.

L’exemple suivant de balisage de contrôle Menu montre l’ensemble de la propriété StaticPopOutImageUrl à l’aide d’un chemin qui contient une barre oblique inverse. Dans ASP.NET 4, l’image spécifiée dans la propriété ne sera pas affichée.

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical 
    target="_blank" 
    StaticPopOutImageTextFormatString="More..."
    StaticPopOutImageUrl="Images\Popout.gif"   
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

Pour corriger ce problème, modifiez les valeurs de chemin d’accès spécifiées dans les propriétés StaticPopOutImageUrl et DynamicPopOutImageUrl pour utiliser des barres obliques (/). L’exemple suivant illustre cette modification :

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical 
    target="_blank" 
    StaticPopOutImageTextFormatString="More..."
    StaticPopOutImageUrl="Images/Popout.gif"   
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

Notez que les applications qui ont été migrées à partir de versions antérieures de ASP.NET vers ASP.NET 4 peuvent également être affectées, car la propriété MenuItem.PopOutImageUrl a été modifiée. Pour plus d’informations, consultez La propriété MenuItem.PopOutImageUrl ne parvient pas à restituer une image dans ASP.NET 4 ailleurs dans ce document.

Clause d'exclusion de responsabilité

Ce document est une version préliminaire et peut être modifié substantiellement avant le lancement de la mise en production commerciale finale du logiciel qu’il décrit.

Les informations contenues dans le présent document reflètent l'opinion de Microsoft Corporation sur les sujets abordés à la date de publication. Microsoft se doit de s'adapter aux conditions fluctuantes du marché, et cette opinion ne peut être considérée comme un engagement de sa part. Microsoft ne peut garantir la véracité de toute information présentée après la date de publication.

Ce livre blanc est fourni à titre d'information uniquement. MICROSOFT NE FOURNIT AUCUNE GARANTIE, EXPRESSE, IMPLICITE OU LÉGALE, QUANT AUX INFORMATIONS CONTENUES DANS CE DOCUMENT.

L’utilisateur est tenu d’observer la réglementation relative aux droits d’auteur applicable dans son pays. Aucune partie de ce document ne peut être reproduite, stockée ou introduite dans un système de restitution, ou transmise à quelque fin ou par quelque moyen que ce soit (électronique, mécanique, photocopie, enregistrement ou autre) sans la permission expresse et écrite de Microsoft Corporation.

Les produits mentionnés dans ce document peuvent faire l'objet de brevets, de dépôts de brevets en cours, de marques, de droits d'auteur ou d'autres droits de propriété intellectuelle et industrielle de Microsoft. Sauf stipulation expresse contraire d'un contrat de licence écrit de Microsoft, la fourniture de ce document n'a pas pour effet de vous concéder une licence sur ces brevets, marques, droits d'auteur ou autres droits de propriété intellectuelle.

Sauf indication contraire, les exemples d’entreprises, d’organisations, de produits, de noms de domaine, d’adresses e-mail, de logos, de personnes, de lieux et d’événements représentés dans les présentes sont fictifs, et aucune association avec une société réelle, organization, produit, nom de domaine, adresse e-mail, logo, personne, lieu ou événement n’est prévue ou ne doit être déduite.

Microsoft et Windows sont soit des marques déposées de Microsoft Corporation, soit des marques de Microsoft Corporation aux États-Unis d'Amérique et/ou dans d'autres pays.

Les noms des sociétés et des produits mentionnés dans le présent document peuvent être des marques de leurs propriétaires respectifs.

Partager via

Changements importants dans ASP.NET 4

Contenu

Paramètre ControlRenderingCompatibilityVersion dans le fichier Web.config

Modifications du clientIDMode

HtmlEncode et UrlEncode Now Encodent des guillemets uniques

ASP.NET Page (.aspx) L’analyseur est plus strict

Fichiers de définition de navigateur mis à jour

System.Web.Mobile.dll supprimé du fichier de configuration web racine

validation de requête ASP.NET

L’algorithme de hachage par défaut est maintenant HMACSHA256

Résolution de ces problèmes

ASP.NET 4 applications enfants ne parviennent pas à démarrer lorsque les applications ASP.NET 2.0 ou ASP.NET 3.5 ne parviennent pas à démarrer

Étape 1 (IIS 7 ou IIS 7.5 uniquement)

Étape 2 (toutes les versions d’IIS)

ASP.NET 4 sites web ne parviennent pas à démarrer sur les ordinateurs sur lesquels SharePoint est installé

La propriété HttpRequest.FilePath n’inclut plus de valeurs PathInfo

ASP.NET applications 2.0 peuvent générer des erreurs HttpException qui référencent eurl.axd

Option 1 :

Option 2 :

Option 3

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

Modifications apportées à l’implémentation ASP.NET Code Access Security (CAS)

MembershipUser et d’autres types dans l’espace de noms System.Web.Security ont été déplacés

Modifications de la mise en cache de sortie pour varier * en-tête HTTP

Les types System.Web.Security pour Passport sont obsolètes

La propriété MenuItem.PopOutImageUrl ne parvient pas à restituer une image dans ASP.NET 4

Menu.StaticPopOutImageUrl et Menu.DynamicPopOutImageUrl Ne parviennent pas à restituer les images lorsque les chemins contiennent des barres obliques inverses

Clause d'exclusion de responsabilité

Commentaires

Ressources supplémentaires