Quelle est la différence entre le mode de pipeline «classique» et «intégré» dans IIS7?

J’étais en train de déployer une application ASP.NET MVC hier soir et j’ai découvert que le déploiement de IIS7 en mode intégré était moins difficile. Ma question est quelle est la différence? Et quelles sont les implications de l’utilisation de l’un ou de l’autre?

Le mode classique (le seul mode dans IIS6 et inférieur) est un mode où IIS fonctionne uniquement avec les extensions ISAPI et les filtres ISAPI directement. En fait, dans ce mode, ASP.NET est juste une extension ISAPI (aspnet_isapi.dll) et un filtre ISAPI (aspnet_filter.dll). IIS traite simplement ASP.NET comme un plug-in externe implémenté dans ISAPI et fonctionne comme une boîte noire (et uniquement lorsqu’il doit envoyer la demande à ASP.NET). Dans ce mode, ASP.NET n’est pas très différent de PHP ou d’autres technologies pour IIS.

Le mode intégré, en revanche, est un nouveau mode dans IIS7 où le pipeline IIS est étroitement intégré (c’est-à-dire est identique) que le pipeline de demandes ASP.NET. ASP.NET peut voir toutes les demandes qu’il veut et manipuler les choses en cours de route. ASP.NET n’est plus traité comme un plug-in externe. Il est complètement mélangé et intégré dans IIS. Dans ce mode, ASP.NET HttpModule possède pratiquement autant de puissance qu’un filtre ISAPI et ASP.NET HttpHandler peut avoir des capacités presque équivalentes à celles d’une extension ISAPI. Dans ce mode, ASP.NET fait essentiellement partie d’IIS.

Mode pool d’applications intégré

Lorsqu’un pool d’applications est en mode intégré, vous pouvez tirer parti de l’architecture de traitement des demandes intégrée d’IIS et d’ASP.NET. Lorsqu’un processus de travail dans un pool d’applications reçoit une demande, la demande passe par une liste ordonnée d’événements. Chaque événement appelle les modules natifs et gérés nécessaires pour traiter des parties de la demande et générer la réponse.

L’exécution de pools d’applications en mode intégré présente plusieurs avantages. Premièrement, les modèles de traitement des demandes d’IIS et d’ASP.NET sont intégrés dans un modèle de processus unifié. Ce modèle élimine les étapes précédemment dupliquées dans IIS et ASP.NET, telles que l’authentification. En outre, le mode intégré permet la disponibilité des fonctionnalités gérées pour tous les types de contenu.

Mode pool d’applications classique

Lorsqu’un pool d’applications est en mode classique, IIS 7.0 gère les demandes comme dans le mode d’isolation du processus de travail IIS 6.0. Les demandes ASP.NET passent d’abord par des étapes de traitement natives dans IIS, puis sont routées vers Aspnet_isapi.dll pour le traitement du code managé dans l’environnement d’exécution géré. Enfin, la demande est renvoyée via IIS pour envoyer la réponse.

Cette séparation des modèles de traitement des demandes IIS et ASP.NET entraîne la duplication de certaines étapes du traitement, telles que l’authentification et l’autorisation. En outre, les fonctionnalités de code managé, telles que l’authentification par formulaire, ne sont disponibles que pour les applications ou applications ASP.NET pour lesquelles un script a mappé toutes les demandes à traiter par aspnet_isapi.dll.

Veillez à tester la compatibilité de vos applications existantes en mode intégré avant de mettre à niveau un environnement de production vers IIS 7.0 et en atsortingbuant des applications aux pools d’applications en mode intégré. Vous ne devez append une application à un pool d’applications qu’en mode classique si l’application ne fonctionne pas en mode intégré. Par exemple, votre application peut s’appuyer sur un jeton d’authentification transmis d’IIS à l’environnement d’exécution géré et, en raison de la nouvelle architecture d’IIS 7.0, le processus interrompt votre application.

Tiré de: Quelle est la différence entre DefaultAppPool et Classic .NET AppPool dans IIS7?

Source originale: Introduction à l’architecture IIS

IIS 6.0 et versions précédentes:

ASP.NET intégré à IIS via une extension ISAPI, une API C (API basée sur le langage de programmation C) et expose son propre modèle de traitement des demandes et des applications.

Cela a permis de mettre en évidence deux pipelines serveur (requête / réponse) distincts, un pour les filtres et composants d’extension ISAPI natifs, et un autre pour les composants d’application gérés. Les composants ASP.NET s’exécuteraient entièrement à l’intérieur de la bulle d’extension ASP.NET ISAPI ET UNIQUEMENT pour les demandes mappées à ASP.NET dans la configuration de mappage de script IIS.

Demandes adressées à des types de contenu non ASP.NET: – les images, les fichiers texte, les pages HTML et les pages ASP sans script ont été traités par IIS ou d’autres extensions ISAPI et ne sont PAS visibles par ASP.NET.

La principale limitation de ce modèle était que les services fournis par les modules ASP.NET et le code d’application ASP.NET personnalisé n’étaient PAS disponibles pour les demandes non ASP.NET.

Qu’est-ce qu’un MAP SCRIPT?

Les mappes de script permettent d’associer des extensions de fichiers au gestionnaire ISAPI qui s’exécute lorsque ce type de fichier est demandé. La mappe de script a également un paramètre facultatif qui vérifie que le fichier physique associé à la demande existe avant d’autoriser le traitement de la demande

Un bon exemple peut être seen here

IIS 7 et supérieur

IIS 7.0 et les versions ultérieures ont été entièrement repensées pour fournir une nouvelle interface ISAPI basée sur une API C ++.

IIS 7.0 et versions ultérieures intègrent le moteur d’exécution ASP.NET aux fonctionnalités de base du serveur Web, en fournissant un pipeline de traitement des demandes unifié (unique) exposé aux composants natifs et gérés, appelés modules (IHttpModules).

Cela signifie que IIS 7 traite les demandes qui arrivent pour tout type de contenu, à la fois avec les NON ASP.NET Modules / native IIS modules et ASP.NET modules fournissant le traitement des requêtes à toutes les étapes . .html, fichiers statiques) peuvent être gérés par des modules .NET.

  • Vous pouvez créer de nouveaux modules gérés ( IHttpModule ) capables de s’exécuter pour tout le contenu de l’application et fournissant un ensemble amélioré de services de traitement des demandes à votre application.
  • Ajouter de nouveaux gestionnaires gérés ( IHttpHandler )

En mode classique, IIS fonctionne directement avec les extensions ISAPI et les filtres ISAPI. Et utilise deux lignes de conduite, une pour le code natif et l’autre pour le code géré. Vous pouvez simplement dire que, en mode Classic, IIS 7.x fonctionne comme IIS 6 et que vous ne tirez aucun avantage supplémentaire des fonctionnalités d’IIS 7.x.

En mode intégré, IIS et ASP.Net sont étroitement liés plutôt que de ne compter que deux DLL sur Asp.net, comme dans le cas du mode classique.

Mode classique En règle générale, le déplacement d’une application Web d’IIS 6.0 vers le mode classique d’IIS 7.0 nécessite uniquement que vous placiez l’application dans un pool d’applications qui s’exécute en mode classique. Par exemple, lorsque vous installez IIS 7.0 avec, par défaut, le serveur Web est configuré pour fonctionner en mode intégré. Il est également configuré pour s’exécuter sous le pool d’applications par défaut, appelé DefaultAppPool. Pour exécuter une application Web en mode classique, utilisez l’application Classic.NETAppPool ou créez un nouveau pool d’applications configuré pour s’exécuter en mode classique. Pour plus d’informations sur la création d’un pool d’applications, voir Créer un pool d’applications. Tous les modules personnalisés qui implémentent l’interface IHttpModule dans une application qui s’exécute en mode classique sont uniquement informés des demandes de pipeline gérées par le runtime ASP.NET. Par exemple, ils sont informés des demandes de page .aspx. Le cycle de vie de l’application pour le mode Classic est identique au cycle de vie d’ASP.NET dans IIS 6.0. Pour plus d’informations, consultez Vue d’ensemble du cycle de vie des applications ASP.NET pour IIS 5.0 et 6.0. Si une application qui s’exécute en mode classique contient un gestionnaire nécessitant une mappe de script pour gérer une extension personnalisée dans IIS, vous devez enregistrer le gestionnaire dans le groupe httpHandler et le groupe de gestionnaires. Vous mappez l’extension de nom de fichier personnalisée à l’extension ISAPI ASP.NET (Aspnet_isapi.dll) en spécifiant les atsortingbuts modules et scriptProcessor dans l’élément gestionnaire. Ces atsortingbuts spécifient que le module qui définit le gestionnaire est une extension ISAPI et qu’ils spécifient le chemin de cette extension. Voici comment IIS 7.0 en mode classique offre une compatibilité descendante avec les versions antérieures d’IIS. Toutefois, si vous exécutez l’application en mode intégré, vous devez supprimer les atsortingbuts de modules et de scriptProcessor. Pour plus d’informations, consultez Procédure: configurer une extension de gestionnaire HTTP dans IIS. Lorsque vous déplacez une application Web d’IIS 6.0 vers le mode Classique, il est impossible de travailler en mode intégré sans modifications. Si vous passez d’une application du mode classique au mode intégré (et modifiez les modules et les gestionnaires personnalisés), vous devrez peut-être apporter des modifications supplémentaires pour que l’application s’exécute correctement en mode intégré. La section suivante de cette rubrique explique comment déplacer une application en mode intégré IIS 7.0.

Mode intégré Les applications Web qui n’incluent pas de modules ou de gestionnaires personnalisés fonctionnent généralement sans modification du mode intégré dans IIS 7.0. Les applications Web qui reposent sur des modules ou des gestionnaires personnalisés nécessitent les étapes suivantes pour permettre à l’application de s’exécuter en mode intégré: Enregistrez les modules et les gestionnaires personnalisés dans la section system.webServer du fichier Web.config en utilisant l’une des méthodes décrites dans la section Migration. une section Web Config File to Integrated Mode plus loin dans cette rubrique. Définissez des gestionnaires d’événements pour les événements de pipeline de demandes HttpApplication, tels que BeginRequest et EndRequest, uniquement dans la méthode Init du module personnalisé. Assurez-vous que vous avez résolu tous les problèmes décrits dans la section «Différences connues entre le mode intégré et le mode classique» de la section Mise à niveau des applications ASP.NET vers IIS 7.0: Différences entre le mode intégré d’IIS 7.0 et le mode classique. Les modules qui implémentent l’interface IHttpModule sont appelés modules de code géré car ils sont générés à l’aide du .NET Framework. Les modules de code géré peuvent être enregistrés au niveau du serveur ou au niveau de l’application. Les modules de code natif sont des DLL (code non géré) enregistrés uniquement au niveau du serveur. Les fonctionnalités principales d’ASP.NET, telles que l’état de session et l’authentification par formulaires, sont implémentées en tant que modules gérés en mode intégré. Lorsque vous déplacez une application du mode Classique au mode Intégré, vous pouvez laisser des enregistrements personnalisés de modules et de gestionnaires pour le mode Classique, ou vous pouvez les supprimer. Si vous ne supprimez pas les enregistrements httpModules et httpHandlers utilisés en mode classique, vous devez définir l’atsortingbut validateIntegratedModeConfiguration de l’élément de validation sur false pour éviter les erreurs. L’élément de validation est un élément enfant de l’élément system.webServer. Pour plus d’informations, voir la section «Désactivation du message de migration» dans l’intégration ASP.NET avec IIS 7.0.