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


Je déployais une application ASP.NET MVC la nuit dernière, et j'ai découvert qu'il est moins de travail à déployer avec IIS7 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?


448
2018-04-03 23:10


origine


Réponses:


Le mode classique (le seul mode dans IIS6 et ci-dessous) 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 ASP.NET comme un plugin externe implémenté dans ISAPI et fonctionne comme une boîte noire (et seulement quand il doit donner la requête à ASP.NET). Dans ce mode, ASP.NET n'est pas très différent de PHP ou d'autres technologies pour IIS.

D'un autre côté, le mode intégré est un nouveau mode dans IIS7 où le pipeline IIS est étroitement intégré (c'est-à-dire identique) au pipeline de requêtes ASP.NET. ASP.NET peut voir toutes les demandes qu'il souhaite 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 HttpModules ont pratiquement autant de puissance qu'un filtre ISAPI et ASP.NET HttpHandlers peut avoir des capacités presque équivalentes à celles d'une extension ISAPI. Dans ce mode, ASP.NET fait essentiellement partie d'IIS.


614
2018-04-03 23:22



Mode de pool d'applications intégré

Lorsqu'un pool d'applications est en mode intégré, vous pouvez profiter   de l'architecture intégrée de traitement des requêtes de IIS et ASP.NET.   Lorsqu'un processus de travail dans un pool d'applications reçoit une demande, le   demande passe à travers une liste ordonnée d'événements. Chaque événement appelle le   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 dans Integrated   mode. Tout d'abord, les modèles de traitement des demandes de IIS et ASP.NET sont   intégré dans un modèle de processus unifié. Ce modèle élimine les étapes   qui étaient précédemment dupliqués dans IIS et ASP.NET, tels que   authentification. De plus, le mode intégré permet la disponibilité   des fonctionnalités gérées à tous les types de contenu.

Mode de 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 vont d'abord   à travers les étapes de traitement natives dans IIS et sont ensuite routés vers   Aspnet_isapi.dll pour le traitement du code managé dans le gestionnaire   runtime. Enfin, la requête est renvoyée via IIS pour envoyer le   réponse.

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

Assurez-vous de tester la compatibilité de vos applications existantes   Mode intégré avant la mise à niveau d'un environnement de production vers IIS 7.0   et affecter des applications aux pools d'applications en mode intégré.   Vous ne devez ajouter une application à un pool d'applications que dans Classic   mode si l'application ne fonctionne pas en mode intégré. Par exemple,   votre application peut s'appuyer sur un jeton d'authentification transmis depuis IIS   au runtime géré et, en raison de la nouvelle architecture dans IIS 7.0,   le processus casse votre application.

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

Source primaire: Introduction à l'architecture IIS


100
2017-12-28 09:42



IIS 6.0 et versions antérieures: 

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

Cela a exposé efficacement deux pipelines de serveur (demande / réponse) distincts, un pour les filtres ISAPI natifs et les composants d'extension, et un autre pour les composants d'application gérés. Les composants ASP.NET s'exécuteraient entièrement dans la bulle d'extension ASP.NET ISAPI ET SEULEMENT  pour les demandes mappées à ASP.NET dans la configuration de mappe de script IIS.

Demandes de types de contenu non ASP.NET: - images, fichiers texte, pages HTML et pages ASP sans script, ont été traitées par IIS ou d'autres extensions ISAPI et n'étaient 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 requêtes non ASP.NET

Qu'est-ce qu'une CARTE SCRIPT?

Les mappages de script sont utilisés pour 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 runtime ASP.NET avec les fonctionnalités de base du serveur Web, fournissant un pipeline de traitement des requêtes unifié (unique) qui est 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, avec les deux NON ASP.NET Modules / native IIS modules et ASP.NET modules fournir un traitement des demandes à toutes les étapes  C'est la raison pour laquelle les types de contenu NON ASP.NET (.html, fichiers statiques) peuvent être gérés par des modules .NET.

  • Vous pouvez créer 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 des demandes à votre application.
  • Ajouter de nouveaux gestionnaires gérés ( IHttpHandler)

11
2017-09-25 15:25



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 managé. Vous pouvez simplement dire qu'en mode classique, IIS 7.x fonctionne comme IIS 6 et que vous ne bénéficiez pas de fonctionnalités supplémentaires de IIS 7.x.

En mode intégré IIS et ASP.Net sont étroitement couplés plutôt qu'en fonction de seulement deux DLL sur Asp.net comme dans le cas du mode classique.


5
2018-02-21 00:49



Mode classique Généralement, le déplacement d'une application Web à partir d'IIS 6.0 vers IIS 7.0 en mode classique 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 notifiés sur les demandes de pipeline qui sont 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 qui nécessite 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é à l'extension ASP.NET ISAPI (Aspnet_isapi.dll) en spécifiant les modules et les attributs scriptProcessor dans l'élément de gestionnaire. Ces attributs spécifient que le module qui définit le gestionnaire est une extension ISAPI et qu'ils spécifient le chemin de cette extension. C'est ainsi que IIS 7.0 en mode Classic fournit 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 attributs de modules et de scriptProcessor. Pour plus d'informations, consultez Comment: 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 que vous modifiez des modules et des gestionnaires personnalisés), vous devrez peut-être effectuer 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 vers le 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 des modules et des 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 d'un fichier Web Config vers le mode intégré 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 les problèmes décrits dans la section «Différences connues entre le mode intégré et le mode classique» de Mise à niveau d'applications ASP.NET vers IIS 7.0: Différences entre le mode intégré 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 managé 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 vers le mode Intégré, vous pouvez laisser des modules personnalisés et des enregistrements 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 Classic, vous devez définir l'attribut 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.


4