Mise à niveau ASP.NET 1.1 vers IIS 7.0 sur Windows Vista et Windows Server 2008

par l’équipe IIS

Introduction

Pour les développeurs d’applications ASP.NET qui passent au système d’exploitation Windows Vista™ ou ultérieur, IIS 7.0 et versions ultérieures représentent une avancée significative par rapport aux versions IIS antérieures. Le mode intégré IIS offre une sécurité accrue et de nouvelles possibilités d’application, entre autres améliorations.

La plupart des développeurs qui passent à Windows Vista effectuent la mise à niveau entre le système d’exploitation Microsoft Windows® XP et Windows Vista et mettent à niveau leurs applications ASP.NET dans le processus. Ou ils installent sur Windows Vista les applications ASP.NET développées sur d’autres systèmes d’exploitation Windows.

Ce document détaille les étapes importantes post-installation et après la mise à niveau qui doivent être effectuées pour que les applications fonctionnent sur le nouveau système d’exploitation. Il décrit les modifications entre le mode Classique et le mode Intégré IIS qui affectent les applications ASP.NET, et indique comment contourner ces problèmes connus.

L’une des améliorations significatives apportées à IIS 7.0 et versions ultérieures est une fonctionnalité de pipeline intégrée qui permet aux applications web d’utiliser un seul pipeline de traitement des requêtes à partir d’applications de code managé ou non managé. En outre, le nouveau modèle de pipeline réduit le comportement redondant qui résulte de deux implémentations distinctes de la même fonctionnalité.

Par exemple, dans les versions précédentes, IIS et ASP.NET implémentaient des pipelines de requête distincts qui ne partageaient pas l’accès aux événements et aux modules de gestionnaire. L’authentification a été effectuée indépendamment au sein de chaque pipeline. Dans le nouveau modèle, l’authentification peut être effectuée une seule fois pour IIS et ASP.NET.

Voici d’autres avantages de cette intégration :

• Des services ASP.NET tels que l’authentification par formulaire et les rôles, qui fonctionnent avec certains types de contenu IIS, par exemple des pages ASP statiques et classiques.
• Les fonctionnalités IIS s’étendent au code managé et aux modules de pipeline ASP.NET, au lieu d’utiliser uniquement des extensions ISAPI ou CGI.
• Résolution simplifiée des problèmes résultant de l’intégration du suivi des événements et de la journalisation des erreurs.
• Partage de la configuration d’application entre ASP.NET et IIS.

Cet article examine les problèmes de compatibilité pour les applications ASP.NET qui migrent des versions antérieures d’IIS vers IIS 7.0 et versions ultérieures, et se concentre spécifiquement sur les différences liées à la transition du mode Classique à l’utilisation du pipeline en mode intégré.

Pour obtenir une vue d’ensemble des fonctionnalités et avantages de l’intégration d’ASP.NET et IIS, consultez l’article Intégration d’ASP.NET à IIS 7.0 et versions ultérieures.

Mise à niveau des versions antérieures d’IIS vers Windows Vista

Le graphique suivant montre la disponibilité d’IIS 7.0 sur les versions disponibles de Windows Vista :

Scénarios de mise à niveau ASP.NET sur Windows Vista

Le tableau suivant présente brièvement les chemins de mise à niveau pris en charge pour ASP.NET sur les versions antérieures des systèmes d’exploitation Windows à ASP.NET sur Windows Vista. Lorsque des problèmes sont signalés, consultez les sections qui suivent pour plus d’informations sur les restrictions et limitations de mise à niveau.

Le tableau indique également que les mises à niveau des versions du système d’exploitation serveur vers les versions du système d’exploitation client ne sont pas disponibles. Au lieu de cela, vous devez effectuer une nouvelle installation de Vista sur un ordinateur avec le système d’exploitation serveur actuellement installé.

Configuration de l’application post-installation

Immédiatement après une installation ou une mise à niveau vers Windows Vista, les utilisateurs doivent effectuer des étapes de configuration supplémentaires pour permettre aux applications de fonctionner. La configuration post-installation dépend de la version ASP.NET utilisée par chaque application.

Configuration d’applications ASP.NET 1.1

Avant d’installer .NET Framework 1.1 (nécessaire si vous exécutez des applications ASP.NET 1.1), les utilisateurs doivent effectuer les deux étapes suivantes pour activer les applications ASP.NET :

Procédure

Chaque pool d’applications IIS qui exécute une application ASP.NET doit être configuré explicitement à l’aide de la version .NET Framework qui correspond à la version ASP.NET utilisée pour l’application. Vous ne pouvez exécuter qu’une seule version de ASP.NET par pool d’applications. Vous devez donc utiliser des pools d’applications distincts pour chaque version ASP.NET.

Sur la console IIS Manager, ouvrez Pools d’applications, puis cliquez avec le bouton droit sur un pool d’applications, et sélectionnez Paramètres de base. Dans la boîte de dialogue Modifier le pool d’applications affichée à la Figure 1, sélectionnez la version de .NET Framework qui correspond aux applications configurées dans le pool d’applications, puis cliquez sur OK.

Figure 1 : modifier les paramètres du pool d’applications

Utilisation d’ASP.NET 1.1 en mode classique

ASP.NET 1.1 utilise une extension ISAPI IIS lors de l’exécution en mode Classique, qui est le paramètre par défaut pour l’installation ou mise à niveau suivante ASP.NET (notez que ASP.NET 2.0 peut également s’exécuter en mode intégré sur Windows Vista, ce qui ne nécessite pas d’extension ISAPI).

Vous devez autoriser explicitement la version d’ASP.NET utilisée par vos applications à l’aide de la configuration des restrictions ISAPI et CGI sur la console de gestion IIS. Ouvrez IIS Manager et sélectionnez Restrictions ISAPI et CGI. Dans la page Restrictions ISAPI et CGI, sélectionnez chaque version d’ASP.NET définie sur Non autorisé dans la colonne Restriction, puis cliquez sur le lien Autorisé sur le côté droit de la page pour modifier le paramètre en Autorisé.

La figure 2 montre un exemple de la page Restrictions ISAPI et CGI avec la version de l’assembly Aspnet_isapi.dll utilisé pour ASP.NET 1.1 sélectionnée. Dans la Figure, le paramètre de cette extension ISAPI doit passer de Non autorisé à Autorisé.

Figure 2 : liste des restrictions ISAPI et CGI

Configuration d’applications ASP.NET 2.0

.NET Framework 2.0 est installé pendant l’installation de Windows Vista et, par conséquent, ASP.NET 2.0 est déjà présent sur le serveur après l’installation. Toutefois, pour terminer la configuration d’ASP.NET sur Vista pour applications ASP.NET 2.0, les utilisateurs doivent effectuer les deux étapes suivantes :

Étape 1

Dans le Gestionnaire de package Windows Vista (Panneau de configuration\Programmes et fonctionnalités\Activer ou désactiver les fonctionnalités Windows), sélectionnez ASP.NET comme illustré dans la Figure 3, puis cliquez sur OK.

Figure 3 : installation de Windows Vista - Fonctionnalités Windows

Étape 2

Chaque pool d’applications IIS qui exécute une application ASP.NET doit être configuré explicitement à l’aide de la version .NET Framework qui correspond à la version ASP.NET utilisée pour l’application. Vous ne pouvez exécuter qu’une seule version de ASP.NET par pool d’applications. Vous devez donc utiliser des pools d’applications distincts pour chaque version ASP.NET.

Dans IIS Manager, ouvrez les pools d’applications, puis cliquez avec le bouton droit sur un pool d’applications ; ensuite, sélectionnez Paramètres de base. Dans la boîte de dialogue Modifier le pool d’applications affichée sur la Figure 4, sélectionnez la version .NET Framework qui correspond aux applications configurées dans le pool d’applications, puis cliquez sur OK.

Figure 4 : pool d’applications et mode intégré

Paramètres du pool d'applications

Lors de la mise à niveau des applications ASP.NET sur des versions antérieures de systèmes d’exploitation Windows vers Windows Vista, les applications sont configurées dans les pools d’applications en fonction des paramètres d’isolation des applications IIS, comme suit :

ASP.NET v1.0 n’est pas pris en charge sur Windows Vista

.NET Framework 1.0 n’est pas pris en charge sur Windows Vista. Par conséquent, les applications ASP.NET 1.0 doivent être mises à niveau vers ASP.NET 1.1 minimum. Nous vous recommandons vivement de mettre à niveau vos applications ASP.NET 1.0 vers ASP.NET 2.0 afin de bénéficier des meilleures performances et des fonctionnalités de maintenance des versions ultérieures d'ASP.NET.

Gestionnaires HTTP

Dans une mise à niveau vers IIS 7.0 et versions ultérieures sur Windows Vista, seuls les gestionnaires HTTP préconditionnés, configurés au niveau global, sont mis à niveau. Les gestionnaires configurés au niveau du site ne sont pas mis à niveau.

Prise en charge de l'exécution côte à côte

Vous pouvez exécuter des applications développées sur différentes versions d’ASP.NET (par exemple, 1.1 et 2.0) côte à côte sur IIS. Vous devez configurer les applications dans un pool d’applications IIS. Ce pool doit être configuré pour la version d’ASP.NET pour laquelle l’application a été développée. Vous ne pouvez configurer qu’une seule version d’ASP.NET par pool d’applications.

.NET Framework 1.1 nécessite la configuration de WoW 64 sur Windows Vista 64 bits

ASP.NET n’est pas configuré correctement si .NET Framework 1.1 est installé sur les versions 64 bits de Windows Vista. Après avoir installé .NET Framework 1.1 sur les versions 64 bits de Windows Vista, vous devez configurer manuellement les applications pour qu’elles s’exécutent à l’aide de WOW 64 au niveau global, à l’aide de l’outil d’administration IIS.

Configuration du mode pipeline utilisé par une application

IIS est configuré pour utiliser le nouveau mode intégré pour les nouvelles applications. C’est le paramétrage par défaut. Le mode pipeline est configuré à l’aide des paramètres du pool d’applications. Modifiez ces paramètres à l’aide de l’un des éléments suivants :

• Outil d'administration IIS
• Outil de ligne de commande APPCMD.EXE
• En modifiant le fichier de configuration de l’application avec un éditeur de texte

Si vous mettez à niveau un ordinateur existant vers IIS 7.0 ou version ultérieure, les applications sont par défaut configurées pour s’exécuter en mode Classique. Le mode Classique offre une compatibilité pour les applications qui ont des dépendances spécifiques sur l’implémentation du pipeline HTTP dans les versions antérieures d’IIS.

Toutefois, si vous importez une application existante sur un ordinateur exécutant IIS 7.0 et versions ultérieures et que vous copiez le site Web, le mode de pipeline utilisé est déterminé par les paramètres du pool d’applications dans lequel l’application est configurée pour s’exécuter.

Par exemple, si vous copiez l’application sur votre ordinateur et que vous la configurez pour qu’elle s’exécute dans le pool d’applications par défaut, elle s’exécute à l’aide des paramètres de ce pool d’applications qui, par défaut, sont configurés en mode intégré. Pour modifier le mode de pipeline de votre application, modifiez les paramètres du pool d’applications par défaut ou créez un pool d’applications avec les paramètres souhaités.

Pour en savoir plus sur la configuration d’une application existante en vue d’une utilisation du mode intégré, consultez l’article ASP.NET Intégration à IIS 7.0 et versions ultérieures, section intitulée « Migration des applications ASP.NET vers IIS 7.0 et versions ultérieures en mode intégré ». Cela fournit des instructions pour modifier les paramètres de configuration des applications.

Compatibilité

Les modules ASP.NET Pipeline développés avec des versions antérieures d'IIS et configurés ultérieurement pour utiliser le mode intégré avec IIS 7.0 et supérieur peuvent présenter des différences de comportement ou d'autres problèmes de compatibilité. Ces problèmes sont causés par les différences architecturales entre le pipeline dans les versions antérieures d’IIS et la conception modulaire d’IIS 7.0 (et versions ultérieures) et le pipeline HTTP intégré.

Les sections suivantes de cet article décrivent les problèmes de compatibilité potentiels que les applications peuvent rencontrer et proposent des suggesions de solutions. Si une solution suggérée n’est pas pratique à implémenter, configurez votre application pour qu’elle s’exécute en mode Classique afin d’éviter le problème de compatibilité.

Différences connues entre le mode intégré et le mode classique

Voici une liste des problèmes connus entre les deux modes. Lisez attentivement cette liste.

En mode intégré, Application_OnError n’est pas appelé pour les exceptions qui se produisent dans HttpApplication ::Init

En mode intégré, les exceptions qui se produisent pendant l’initialisation d’une application ou d’un module ne peuvent pas être interceptées à l’aide de l’événement Application.Error.

En outre, les applications qui utilisent Server.ClearError pour récupérer à partir d’erreurs ne peuvent pas effacer les erreurs survenues lors de l’initialisation de l’application. Cela permet d’empêcher une application d’ignorer une erreur lors de l’initialisation. Les applications qui consignent les informations d’erreur pour chaque exception qui se produit ne pourront pas consigner les erreurs qui se produisent lors de l’initialisation de l’application, bien que ces erreurs soient signalées à l’aide d’événements Web et de réponses HTTP.

Si une application nécessite l’implémentation de cette gestion des exceptions pendant l’initialisation, elle doit être exécutée en mode Classique plutôt qu’en mode Intégré.

Server.ClearError dans EndRequest n’efface pas le message d’exception en mode Intégré

En mode Intégré, l’appel de Server.ClearError dans EndRequest n’efface pas la réponse d’exception si une exception s’est produite précédemment lors du traitement des requêtes. Les applications qui effacent le message d’exception dans EndRequest ne peuvent pas supprimer la sortie de l’exception de la réponse.

Si une application nécessite l’implémentation de cette gestion des exceptions pendant EndRequest, elle doit être exécutée en mode Classique plutôt qu’en mode Intégré.

Les applications en mode Intégré peuvent écrire dans une réponse dans EndRequest une fois qu’une exception a été mise en forme et écrite dans la réponse

En mode Intégré, il est possible d’écrire et d’afficher une réponse supplémentaire écrite après qu’une exception ait eu lieu.

Cela ne se produit pas en mode Classique. Si une erreur se produit pendant la requête et que l’application écrit dans la réponse dans EndRequest une fois que l’exception s’est produite, les informations de réponse écrites dans EndRequest s’affichent. Cela affecte uniquement les requêtes qui incluent des exceptions non prises en charge.

Pour éviter d’écrire dans la réponse après une exception, une application doit vérifier HttpContext.Error ou HttpResponse.StatusCode avant d’écrire dans la réponse.

En mode Intégré, ASP.NET ne supprime plus le type de contenu lorsque la réponse est vide

En mode Intégré, les gestionnaires ASP.NET génèrent des en-têtes de type de contenu lorsqu’ils sont définis explicitement par un module, même si la réponse est vide. Certaines applications génèrent un type de contenu pour les réponses vides. Si vous le souhaitez, modifiez les applications pour supprimer explicitement l’en-tête Type de contenu en le définissant sur NULL.

Identité Windows différente dans l’authentification par formulaire

Lorsque l’authentification par formulaire est utilisée par une application et que l’accès anonyme est autorisé, l’identité en mode Intégré diffère de l’identité en mode Classique, de la manière suivante :

• ServerVariables["LOGON_USER"] est renseigné.
• Request.LogognUserIdentity utilise les informations d’identification du compte [NT AUTHORITY\NETWORK SERVICE] et non du compte [NT AUTHORITY\INTERNET USER].

Ce comportement se produit parce que l’authentification est effectuée en une seule étape en mode Intégré. À l’inverse, en mode Classique, l’authentification se produit d’abord avec IIS à l’aide de l’accès anonyme, puis avec ASP.NET à l’aide de l’authentification par formulaire. Ainsi, le résultat de l’authentification est toujours un utilisateur unique : l’utilisateur de l’authentification par formulaire. AUTH_USER/LOGON_USER renvoie ce même utilisateur, car les informations d’identification de l’utilisateur d’authentification par formulaire sont synchronisées entre IIS et ASP.NET.

Un effet secondaire est que LOGON_USER, HttpRequest.LogonUserIdentity et l’emprunt d’identité ne peuvent plus accéder aux informations d’identification de l’utilisateur anonyme qu’IIS aurait authentifiées avec le mode Classique.

L’événement DefaultAuthentication_OnAuthenticate ne se déclenche pas en mode Intégré

En mode Intégré, l’événement DefaultAuthenticationModule.Authenticate ne se déclenche plus. En mode Classique, cet événement est déclenché lorsqu’aucune authentification n’a eu lieu. En mode Intégré, une application qui définit le mode d’authentification =None et s’abonne à l’événement DefaultAuthentication.Authenticate reçoit une exception indiquant que cette fonctionnalité n’est pas prise en charge en mode Intégré. Les schémas d’authentification qui s’appuient sur ce modèle ne fonctionnent pas.

Pour contourner ce changement, les applications en mode Intégré peuvent s’abonner à la place à AuthenticateRequest.

En mode Intégré, Request.RawUrl contient la nouvelle chaîne de requête après l’appel de RewritePath

En mode Intégré, une fois RewritePath appelé sur une URL avec une nouvelle chaîne de requête, la propriété Request.RawUrl contient la nouvelle chaîne de requête. En mode Classique, elle contient l’ancienne chaîne de requête.

Pour contourner ce changement, réécrivez votre application afin qu’elle ne dépende pas de l’ancien comportement.

L’authentification des informations d’identification Passport Network n’est pas prise en charge dans Windows Vista

La fonctionnalité d’informations d’identification Passport Network est supprimée de Windows Vista et du système d’exploitation Microsoft Windows Server® 2008. Par conséquent, les applications d’authentification des informations d’identification Passport Network ne fonctionnent pas par défaut en mode ISAPI ou Intégré.

Le module PassportAuthentication ne fait pas partie du pipeline intégré

En mode Intégré, le module Passport Authentication ASP.NET est supprimé du pipeline par défaut. S’il est utilisé par une application, il peut être rajouté au pipeline. Comme indiqué ci-dessus, la fonctionnalité d’informations d’identification Passport Network sous-jacente est supprimée de Windows Vista et de Microsoft Windows Server 2008. Par conséquent, les applications d’authentification des informations d’identification Passport Network ne fonctionnent pas par défaut en mode ISAPI ou Intégré.

Les tickets d’authentification de formulaires volumineux et valides (longueur <= 4096 octets) présents dans la chaîne de requête sont rejetés par IIS 7.0 et versions ultérieures

IIS rejette les demandes avec des tickets ASP.NET sans cookie volumineux (tels que ceux utilisés dans l’authentification par formulaire), les états de session et ID anonymes qui dépassent au total 4 096 octets. Pour des raisons de sécurité, cela empêche les attaques de dépassement de mémoire tampon qui utilisent des chaînes de requête volumineuses. Les applications qui stockent des données personnalisées ou qui utilisent des noms d’utilisateur très volumineux dans des tickets d’authentification par formulaire peuvent voir que les demandes sont rejetées, car les chaînes de requête sont trop volumineuses.

Pour modifier ce comportement, ajustez la taille maximale de chaîne de requête dans la section de configuration du filtrage des requêtes IIS.

En mode Intégré, le délai d’expiration des requêtes ASP.NET est appliqué plusieurs fois pendant la requête, ce qui permet un temps d’exécution plus long

En mode Intégré, le délai d’attente d’exécution de la requête managée est réinitialisé pour chaque nouvelle transition dans le pipeline. Cela signifie que la demande peut utiliser jusqu’à (délai d’attente *(# de notifications de module)), tant que tout délai d’attente unique ne dépasse pas la durée maximale définie pour les délais d’attente.

Les requêtes lentes peuvent ne pas être abandonnées ou prendre beaucoup de temps avant l’abandon, en fonction du nombre de modules ASP.NET et de la façon dont ces modules sont fusionnés. Évitez ce comportement en réduisant la durée du délai d’attente.

Les paramètres de trace ne sont pas transférés vers la page cible Server.Transfer

Le mode Intégré ne prend pas en charge le transfert des paramètres de trace vers la cible d’une opération Server.Transfer.

La méthode Httpcontext.Current.Response.Write() ne peut pas fonctionner dans Application_Onstart()

En mode Intégré, une application ne peut pas appeler Http.Current.Response.Write() dans une méthode Application_Onstart().

HttpRequest.LogonUserIdentity lève une exception en cas d’accès avant PostAuthenticateRequest

En mode Intégré, la propriété HttpRequest.LogonUserIdentity lève une exception en cas d’accès avant PostAuthenticateRequest. Si un module accède à cette propriété avant PostAuthenticateRequest, une exception est levée.

Pour éviter ce comportement : n’accédez pas à cette propriété dans votre application ; ou accédez-y une fois postAuthenticateRequest terminé.

En mode Intégré, les modules ASP.NET recevront la première requête non authentifiée auprès d’IIS 7.0 et versions ultérieures lorsque l’authentification anonyme est désactivée

En mode Intégré, lorsqu’un schéma d’authentification IIS autre que l’authentification anonyme est utilisé, la première requête du client qui ne contient pas les informations d’identification requises est visible pour les modules ASP.NETdans les phases BeginRequest et AuthenticateRequest.

En comparaison, en mode Classique, une application ASP.NET ne voit pas une telle requête, car IIS la rejette avec une erreur 401 avant qu’ASP.NET ait la possibilité de la traiter.

Cela signifie que les modules ASP.NETverront une requête supplémentaire dans les phases BeginRequest et AuthenticateRequest. La requête apparaît dans les événements Web et dans toute consignation personnalisée effectuée dans BeginRequest ou EndRequest.

ASP.NET ne peut pas emprunter l’identité du client jusqu’à PostAuthenticateRequest

En mode Intégré, ASP.NET n’emprunte pas l’identité du client tant que PostAuthenticateEvent n’est pas activé, si l’emprunt d’identité du client est activé pour une application à l’aide du fichier Web.config de l’application ou de Machine.config.

En outre, lorsque l’emprunt d’identité du client est activé, les modules s’exécutant dans les événements BeginRequest et AuthenticateRequest s’exécutent avec l’identité du processus au lieu de l’identité de l’utilisateur authentifié. Cela ne doit pas être un problème, car les modules accèdent rarement aux ressources de ces événements, puisque l’utilisateur authentifié n’a pas encore été établi.

Toutefois, si c’est le cas, l’identité du processus est utilisée pour accéder aux ressources.

En raison de l’élévation possible des droits utilisateur que cette modification peut entraîner, IIS lève une exception lorsque l’emprunt d’identité du client est activé. Cela indique que l’application doit être déplacée en mode Classique ou que cette erreur doit être désactivée s’il peut être confirmé que les ressources sont accessibles dans les événements BeginRequest ou AuthenticateRequest.

L’en-tête Content-Type n’est pas généré lorsque le jeu de caractères et le type de contenu sont définis sur une chaîne vide

HTTP.sys ne génère plus l’en-tête Content-Type lorsqu’il est explicitement défini sur String.Empty. Les applications dont les clients s’appuient sur l’utilisation d’un en-tête Content-Type vide peuvent être affectées par cette modification.

En mode Intégré, les événements synchrones et asynchrones sont déclenchés pour chaque module avant l’exécution du module suivant

En mode Intégré, les événements synchrones et asynchrones sont déclenchés pour chaque module, avant que le serveur passe au module suivant.

Cela diffère du mode Classique, dans lequel toutes les notifications de module asynchrones s’exécutent en premier, suivies de toutes les notifications synchrones. Il ne doit pas y avoir d’effet sur les applications, sauf si elles dépendent de l’ordre (voir « L’ordre des modules est inversé pour PreSendRequestHeaders et PreSendRequestContent lors de l’utilisation du mode intégré » ailleurs dans ce document).

Les en-têtes de réponse sont supprimés en mode Intégré, après avoir appelé ClearHeader dans un IHttpModule personnalisé

En mode Intégré, l’appel de ClearHeaders ne génère pas automatiquement d’en-têtes par défaut. Les applications qui appellent ClearHeaders pour renvoyer les en-têtes à l’état par défaut d’une page .aspx effacent plutôt tous les en-têtes de réponse.

L’utilisation de l’authentification Windows et Forms ensemble en mode Intégré n’est pas prise en charge

En mode intégré, la définition de l’emprunt d’identité=true et l’utilisation de l’authentification par formulaire ne sont pas prises en charge et provoquent une erreur ou un comportement incorrect.

En mode Intégré, IIS 7.0 et versions ultérieures rejettent toujours les nouvelles lignes dans les en-têtes de réponse (même si ASP.NET enableHeaderChecking porte la valeur false)

En mode Intégré, une exception est levée lorsque vous essayez de définir un en-tête de réponse sur une valeur qui contient \r ou \n. En mode Classique, cette valeur est encodée par défaut et transmise si l’encodage d’en-tête est désactivé. Pour des raisons de sécurité, les applications ne doivent pas essayer d’écrire de nouvelles lignes non codées dans les valeurs d’en-tête.

Les événements PreSendRequestHeaders et PreSendRequestContent seront rassemblés pour chaque module

En mode Intégré, les modules qui s’abonnent aux événements PreSendRequestHeaders et PreSendRequestContent sont notifiés ensemble pour les événements PreSendRequestHeaders et PreSendRequestContent.

Par exemple, une application peut s’interrompre si le module A a une dépendance sur le module B exécuté en premier dans PreSendRequestHeaders, avant l’exécution du module A pour PreSendRequestContent, par exemple si le module B modifie l’état de la requête et que le module A en dépend.

L’ordre des modules est inversé pour PreSendRequestHeaders et PreSendRequestContent lors de l’utilisation du mode Intégré

En mode Intégré, les modules qui s’abonnent à PreSendRequestHeaders et PreSendRequestContent seront avertis dans l’ordre opposé de leur apparition dans la section. Les applications qui ont plusieurs modules configurés pour s’exécuter dans l’un de ces événements sont affectées par cette modification s’ils partagent une dépendance vis-à-vis de l’ordre des événements.

Pour contourner ces problèmes, modifiez l’ordre des modules dans la section ou exécutez l’application en mode Classique.

En mode Intégré, les paramètres de thread et de mise en file d’attente sont ignorés

En mode Intégré, ASP.NET, et non IIS, traite les requêtes sur les threads et n’utilise pas la sémantique de thread ou de mise en file d’attente utilisée en mode Classique. En raison de cette différence, les applications peuvent rencontrer un débit ou un comportement de stress différent en mode Intégré par rapport à l’exécution en mode Classique.

Si une erreur de fichier de configuration est rencontrée lors de l’utilisation du mode Intégré, IIS, et non ASP.NET, génère le message d’erreur

Pour les applications s’exécutant en mode Intégré, IIS lit désormais les fichiers de configuration d’application. Par conséquent, si le code XML mal formaté se trouve dans le fichier Web.config ou s’il existe des erreurs de configuration dans le fichier, IIS génère toujours un message d’erreur, et non ASP.NET.

Étant donné que IIS et ASP.NET écrivent les erreurs dans différents formats, le format du message d’erreur diffère selon que l’application s’exécute en mode Intégré ou en mode Classique. Voici un exemple de type d’erreur de fichier de configuration généré par IIS : erreur de configuration d’erreur de serveur interne : le fichier de configuration n'est pas un XML bien formaté

En mode Intégré, les applications ASP.NET doivent s’abonner aux événements de pipeline pendant l’appel Init d’un module

Les applications ASP.NET utilisant le pipeline HTTP ASP.NET peuvent s’abonner aux événements d’application en dehors du pipeline. Toutefois, les applications ASP.NET utilisant le pipeline en mode Intégré IIS doivent maintenant l’abonnement aux événements pendant la méthode Init() du module. L’exemple suivant montre comment un abonnement aux événements est implémenté dans Init :

Public void Init(httpApplication context)
{
    Context.AuthenticateRequest += new EventHandler(this.AuthenticateUser);
}

Pour plus d’informations sur la création de modules IIS, consultez l’article Développer un module à l’aide de .NET.

Ressources complémentaires

Pour plus d’informations sur la mise à niveau vers IIS 7.0 et versions ultérieures sur Windows Vista, consultez l’article consacré à la compatibilité des applications IIS 7.0 sur Windows Vista : Compatibilité et fonctionnalités requises pour Windows Vista.