Quelle est la différence entre le mode de pipeline "classique" et "intégré" dans IIS7?
j'étais en train de déployer un ASP.NET MVC application hier soir, et a découvert qu'il est moins de travail à déployer avec IIS7 mis en mode intégré. Ma question est quelle est la différence? Et quelles sont les implications de l'utilisation de l'un ou de l'autre?
5 réponses
mode classique (le seul mode dans IIS6 et ci-dessous) est un mode où IIS ne fonctionne qu'avec des extensions ISAPI et des 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.) C'est juste des gâteries. ASP.NET comme un plugin externe mis en œuvre dans ISAPI et fonctionne avec lui comme une boîte noire (et seulement quand il a besoin de donner la demande à ASP.NET). Dans ce mode, ASP.NET N'est pas très différent de PHP ou autre technologies pour IIS.
Le mode intégré, par contre, est un nouveau mode dans IIS7 où IIS pipeline est étroitement intégré (c'est-à-dire est exactement le même) que ASP.NET demande pipeline. ASP.NET peut voir chaque demande qu'il veut et manipuler les choses le long du chemin. ASP.NET n'est plus traité comme un plugin externe. C'est complètement mélangé et intégré dans IIS. Dans ce mode, ASP.NET HttpModule s ont essentiellement presque autant de puissance qu'un filtre ISAPI aurait eu et ASP.NET HttpHandler s peut avoir une capacité presque équivalente à celle d'une extension ISAPI. Dans ce mode, ASP.NET est essentiellement une partie de IIS.
d'une application Intégrée de la piscine en mode
Quand un pool d'applications est en mode Intégré, vous pouvez profiter de l'architecture intégrée de traitement des demandes D'IIS et ASP.NET. Lorsqu'un travailleur traite une demande dans un bassin de 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 du demande et de générer des réponse.
Il ya plusieurs avantages à l'exploitation des pools d'applications dans les mode. Tout d'abord, les modèles de traitement des demandes D'IIS et ASP.NET sont intégré dans un modèle de processus unifié. Ce modèle élimine les étapes qui ont déjà été dupliqués dans IIS et ASP.NET, comme Authentication. En outre, le mode intégré permet la disponibilité des fonctionnalités gérées à tous les types de contenu.
application classique mode piscine
Lorsqu'un pool d'applications est en mode Classique, IIS 7.0 traite les requêtes comme dans la version 6.0 de l'IIS, le mode d'isolement du processus par le travailleur. ASP.NET demandes d'abord go par étapes de traitement natif dans IIS et sont ensuite acheminés vers Aspnet_isapi.dll pour le traitement du code géré dans le Runtime. Enfin, la demande est renvoyée par IIS pour envoyer le réponse.
Cette séparation de l'IIS et ASP.NET de traitement des demandes modèle entraîne le dédoublement de certaines étapes de traitement, comme: authentification et autorisation. De plus, les fonctionnalités du code géré, comme l'authentification des formulaires, ne sont disponibles que pour ASP.NET applications ou applications pour lesquelles vous avez script mappé toutes les demandes doivent être traitées par aspnet_isapi.DLL.
assurez-vous de tester vos applications existantes pour la compatibilité Mode intégré avant de transformer un environnement de production en IIS 7.0 et l'attribution applications aux pools d'applications en mode intégré. Vous ne devez ajouter une application à un pool d'application dans Classic mode si l'application ne fonctionne pas en mode Intégré. Exemple, votre application pourrait s'appuyer sur un jeton d'authentification passé de IIS pour la gestion de l'exécution, et, en raison de la nouvelle architecture dans IIS 7.0, le processus casse votre demande.
tiré de: Quelle est la différence entre DefaultAppPool et Classique .NET pool d'applications dans IIS7?
source originale: Introduction à L'Architecture IIS
IIS 6.0 et versions précédentes:
ASP.NET intégré avec IIS via une extension ISAPI, une API C ( Langage de programmation C API ) et exposé son propre modèle d'application et de traitement des requêtes.
cela a effectivement exposé deux pipelines de serveur( requête / réponse ) distincts, un pour les filtres ISAPI natifs et les composants d'extension, et un autre pour les applications gérées composant. ASP.NET les composants s'exécuteraient entièrement à l'intérieur du ASP.NET bulle d'extension ISAPI et seulement pour les requêtes ASP.NET dans la configuration de la carte de script IIS.
ASP.NET types de contenu: - 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 N'étaient pas visibles pour ASP.NET.
la principale limitation de ce modèle était que services offerts par ASP.NET modules et sur mesure ASP.NET le code de la demande n'était pas disponible pour non ASP.NET demandes
Qu'est-ce qu'un SCRIPT MAP ?
Les cartes de Scriptsont utilisées pour associer des extensions de fichiers avec le gestionnaire ISAPI qui s'exécute lorsque ce type de fichier est demandé. Le script map a aussi un paramètre optionnel qui vérifie que le fichier physique associé à la requête existe avant d'autoriser la requête à traiter
un bon exemple peut être seen here
IIS 7 et plus
IIS 7.0 et supérieurs ont été remaniés de fond en comble pour fournir une toute nouvelle ISAPI basée sur L'API C++.
IIS 7.0 and above intègre la ASP.NET exécutez avec la fonctionnalité de base du serveur Web, fournissant un pipeline unifié(simple) de traitement des requêtes qui est exposé aux composants natifs et gérés connus sous le nom de modules ( IHttpModules )
ce qui signifie que IIS 7 traite les requêtes qui arrivent pour n'importe quel type de contenu, avec à la fois NON ASP.NET Modules / native IIS modules et ASP.NET modules fournissant un traitement de requête à toutes les étapes "1519150920 C'est la raison pour laquelle NON ASP.NET types de contenu (.html, fichiers statiques) peuvent être traités par les modules .NET.
- vous pouvez construire de nouveaux modules gérés(
IHttpModule) qui ont la capacité d'Exécuter pour tout le contenu de l'application, et fourni un ensemble amélioré de services de traitement de la demande à votre application. - ajouter de nouveaux gestionnaires (
IHttpHandler)
en mode classique IIS fonctionne avec des extensions ISAPI et filtre directement 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 dans le mode Classique IIS 7.x fonctionne tout comme IIS 6 et vous ne obtenez pas d'avantages supplémentaires de IIS 7.x caractéristiques.
en mode intégré IIS et ASP.Net sont étroitement liés plutôt que de dépendre seulement de deux DLLs sur Asp.net comme en mode classique.
Mode Classique Généralement, le déplacement d'une application Web du mode IIS 6.0 vers le mode IIS 7.0 Classic nécessite seulement que vous mettiez l'application dans un pool d'applications qui est en cours d'exécution en mode Classic. 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 fonctionner sous le pool d'applications par défaut, qui est appelé DefaultAppPool. Pour exécuter une application Web en mode classique, utilisez le Classique.NETAppPool application ou créer un nouveau pool d'applications qui est configuré pour fonctionner en mode Classique. Pour savoir comment créer un bassin d'applications, consultez Créer un bassin d'applications. Tous les modules personnalisés qui implémentent L'interface IHttpModule dans une application qui tourne en mode classique ne sont informés que des requêtes de pipeline qui sont traitées par le ASP.NET c'est parti. Par exemple, ils sont informés de la demande pour un .aspx page. Le cycle de vie de L'application pour le mode classique est comme le cycle de vie pour ASP.NET dans IIS 6.0. Pour en savoir plus, consultez ASP.NET aperçu du Cycle de vie de L'Application IIS 5.0 et 6.0. Si une application qui tourne en mode Classique contient un handler qui nécessite un script map pour gérer une extension personnalisée dans IIS, vous devez enregistrer le handler à la fois dans le groupe httpHandler et dans le groupe handler. Vous mappez l'extension custom file-name ASP.NET extension ISAPI (Aspnet_isapi.dll) en spécifiant les modules et les attributs de scriptProcessor dans le gestionnaire d'élément. Ces attributs spécifient que le module qui définit le gestionnaire est une extension ISAPI, et ils spécifient le chemin de cette extension. C'est ainsi que IIS 7.0 en mode classique offre une rétrocompatibilité avec les versions précédentes de IIS. Cependant, si vous exécutez l'application en mode intégré, vous devez supprimer les modules et les attributs de scriptProcessor. Pour plus d'informations, voir comment configurer une Extension de gestionnaire HTTP dans IIS. Lorsque vous déplacez une application Web de IIS 6.0 à Classic mode, il n'est pas garanti pour fonctionner en mode Intégré sans modifications. Si vous passez d'une application en mode classique à une application en mode intégré (et changez les modules et les gestionnaires personnalisés), vous devrez peut-être apporter des modifications supplémentaires pour que l'application tourne 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é Applications Web qui ne comprennent pas de modules personnalisés ou les handlers fonctionneront généralement sans changement de mode intégré dans IIS 7.0. Les applications Web qui s'appuient sur des modules ou des gestionnaires personnalisés nécessitent les étapes suivantes pour permettre à l'application de fonctionner en mode intégré: Enregistrez les modules personnalisés et les gestionnaires dans le système.serveur section du site Web.fichier de configuration en utilisant l'une des méthodes décrites dans la migration D'un fichier de configuration Web vers la section Mode intégré plus loin dans ce sujet. Définir des gestionnaires d'événements pour les événements de pipeline de requêtes HttpApplication tels que BeginRequest et EndRequest seulement dans la méthode Init du module personnalisé. Assurez - vous que vous avez abordé toutes les questions discutées dans la section "différences connues entre le Mode intégré et le Mode classique" de la mise à niveau ASP.NET Applications to IIS 7.0: Differences between IIS 7.0 Integrated Mode and Classic mode. Les Modules qui implémentent L'interface IHttpModule sont appelés modules de code géré parce qu'ils sont construits en utilisant le Framework .NET. Les modules de code géré peuvent être enregistrés à niveau du serveur ou au niveau de l'application. Les modules de code natif sont des DLLs (non-managed code) qui ne sont enregistrés qu'au niveau du serveur. Noyau ASP.NET les fonctionnalités, telles que l'état de la session et l'authentification des 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 modules personnalisés et des enregistrements de gestionnaire pour le mode classique, ou vous pouvez les supprimer. Si vous ne supprimez pas les enregistrements httpModules et httpHandlers qui sont utilisés en mode classique, vous devez définir l'attribut validateIntegratedModeConfiguration de l'élément de validation à false pour éviter les erreurs. L'élément validation est un élément enfant du système.le serveur web de l'élément. Pour plus d'informations, voir la section "Désactiver le message de migration" dans ASP.NET intégration avec IIS 7.0.