¿Cuál es la diferencia entre el modo de canalización "clásico" e "integrado" en IIS7?

Question

que estaba desplegando una aplicación ASP.NET MVC anoche, y descubrí que es menos trabajo para desplegar con IIS7 conjunto a modo integrado. Mi pregunta es ¿cuál es la diferencia? ¿Y cuáles son las implicaciones de usar uno u otro?

Answer 1

modo clásico (el único modo en el IIS6 y por debajo) es un modo en el IIS sólo funciona con las extensiones ISAPI y filtros ISAPI directamente. De hecho, en este modo, ASP.NET es solo una extensión ISAPI (aspnet_isapi.dll) y un filtro ISAPI (aspnet_filter.dll). IIS simplemente trata a ASP.NET como un complemento externo implementado en ISAPI y funciona con él como un recuadro negro (y solo cuando necesita dar la solicitud a ASP.NET). En este modo, ASP.NET no es muy diferente de PHP u otras tecnologías para IIS.

El modo integrado, por otro lado, es un nuevo modo en IIS7 donde la interconexión IIS está estrechamente integrada (es decir, es la misma) que la interconexión de solicitudes ASP.NET. ASP.NET puede ver cada solicitud que desee y manipular cosas en el camino. ASP.NET ya no se trata como un complemento externo. Está completamente mezclado e integrado en IIS. En este modo, ASP.NET HttpModule s, básicamente, tienen casi tanta energía como un filtro ISAPI habría tenido y ASP.NET HttpHandler s puede tener una capacidad casi equivalente como una extensión ISAPI podría tener. En este modo, ASP.NET es básicamente una parte de IIS.

Answer 2

modo integrado grupo de aplicaciones

Cuando un grupo de aplicaciones está en el modo integrado, puede aprovechar de la arquitectura de procesamiento de solicitudes integrada de IIS y ASP.NET. Cuando un proceso de trabajo en un grupo de aplicaciones recibe una solicitud, la solicitud pasa por una lista ordenada de eventos. Cada evento llama al módulos nativos y administrados necesarios para procesar porciones de la solicitud y generar la respuesta.

Hay varios beneficios a la ejecución de grupos de aplicaciones en el modo integrado . Primero, los modelos de procesamiento de solicitudes de IIS y ASP.NET son integrados en un modelo de proceso unificado. Este modelo elimina los pasos que previamente se duplicaron en IIS y ASP.NET, como la autenticación . Además, el modo integrado habilita la disponibilidad de funciones administradas para todos los tipos de contenido.

modo de grupo de aplicaciones clásico

Cuando un grupo de aplicaciones está en el modo clásico, IIS 7.0 trata las solicitudes como en el modo de aislamiento de IIS 6.0 proceso de trabajo. solicitudes ASP.NET primera van través de pasos de procesamiento nativos en IIS y luego se encaminan a Aspnet_isapi.dll para el procesamiento de código administrado en el tiempo de ejecución administrado . Finalmente, la solicitud se reenvía a través de IIS para enviar la respuesta .

Esta separación de los modelos de procesamiento de solicitudes IIS y ASP.NET da como resultado la duplicación de algunos pasos de procesamiento, como la autenticación y autorización de . Además, gestionado funciones de código, tales como la autenticación de formularios, solamente están disponibles para ASP.NET aplicaciones o aplicaciones para las que tiene asignada la escritura todos los solicitudes para ser manejados por aspnet_isapi.dll.

Asegúrese de probar sus aplicaciones existentes para la compatibilidad en el modo integrado antes de actualizar un entorno de producción a IIS 7.0 y asignar aplicaciones a grupos de aplicaciones en modo integrado. Solo debe agregar una aplicación a un grupo de aplicaciones en el modo Classic si la aplicación no funciona en modo integrado. Por ejemplo, su aplicación puede confiar en un token de autenticación pasado de IIS al tiempo de ejecución administrado y, debido a la nueva arquitectura en IIS 7.0, , el proceso rompe su aplicación.

Tomado de: What is the difference between DefaultAppPool and Classic .NET AppPool in IIS7?

Fuente original: Introduction to IIS Architecture

Answer 3

En el modo clásico de IIS funciona extensiones ISAPI h y filtros ISAPI directamente. Y utiliza dos líneas de tubería, una para el código nativo y otra para el código administrado. Simplemente puede decir que en el modo Clásico, IIS 7.x funciona igual que IIS 6 y que no obtiene beneficios adicionales de las características de IIS 7.x.

En modo integrado, IIS y ASP.Net están estrechamente conectados en lugar de depender de solo dos DLL en Asp.net como en el caso del modo clásico.

Answer 4

IIS 6.0 y versiones anteriores:

ASP.NET integrado con IIS través de una extensión ISAPI, una API C (Lenguaje de programación API basada en C) y se expusieron su propio modelo de procesamiento de la solicitud y la solicitud .

Esto efectivamente expuso dos tuberías de servidor (solicitud/respuesta) separadas, una para filtros ISAPI nativos y componentes de extensión, y otra para componentes de aplicaciones administradas. Los componentes de ASP.NET se ejecutarían completamente dentro de la burbuja de extensión ISAPI de ASP.NET Y SOLAMENTE para las solicitudes mapeadas a ASP.NET en la configuración del mapa de scripts de IIS.

Solicitudes a tipos de contenido que no sean ASP.NET: - las imágenes, los archivos de texto, las páginas HTML y las páginas ASP sin script fueron procesadas por IIS u otras extensiones ISAPI y NO fueron visibles para ASP.NET.

La principal limitación de este modelo era que los servicios prestados por el código de la aplicación ASP.NET módulos y personalizada ASP.NET no estaban disponibles para ASP.NET no pide

¿Qué es un Texto de mapa?

Los mapas de scripts se utilizan para asociar extensiones de archivo con el controlador ISAPI que se ejecuta cuando se solicita ese tipo de archivo. La asignación de script también tiene una configuración opcional que verifica que existe el archivo físico asociado con la petición antes de permitir que la solicitud sea procesada

Un buen ejemplo puede ser seen here

IIS 7 y por encima de

IIS 7.0 y superior han sido rediseñados desde cero para proporcionar un nuevo ISAPI basado en API de C++.

IIS 7,0 y por encima de integra el tiempo de ejecución ASP.NET con la funcionalidad principal del servidor Web, proporcionando un unificado (single) canalización de procesamiento de petición que se expone a ambos componentes nativos y gestionados conocidos como módulos (IHttpModules)

Lo que esto significa es que IIS 7 procesa las solicitudes que llegan para cualquier tipo de contenido, con NON ASP.NET Modules/native IIS modules y ASP.NET modules proporcionando procesamiento de solicitud en todas las etapasEsta es la razón por la que los tipos de contenido NON ASP.NET (.html, archivos estáticos) pueden ser manejado por módulos .NET.

• Se puede construir nuevos módulos administrados (IHttpModule) que tienen la capacidad de ejecutar aplicaciones de todo el contenido, y proporciona un conjunto mejorado de servicios de procesamiento de solicitud a su aplicación.
• Añadir nuevos controladores administrados (IHttpHandler) Modo Clásico

Answer 5

Por lo general, se mueve una aplicación Web desde IIS 6.0 a IIS 7.0 modo clásico sólo exige que se pone la aplicación en un grupo de aplicaciones que se ejecuta en Modo clásico. Por ejemplo, cuando instala IIS 7.0, de forma predeterminada, el servidor web está configurado para operar en modo integrado. También está configurado para ejecutarse bajo el grupo de aplicaciones predeterminado, que se llama DefaultAppPool. Para ejecutar una aplicación web en modo Clásico, use la aplicación Classic.NETAppPool o cree un nuevo grupo de aplicaciones que esté configurado para ejecutarse en modo Clásico. Para obtener información acerca de cómo crear un grupo de aplicaciones, vea Crear un grupo de aplicaciones. Cualquier módulo personalizado que implemente la interfaz IHttpModule en una aplicación que se ejecuta en modo Clásico solo se notifica sobre las solicitudes de canalización que maneja el tiempo de ejecución de ASP.NET. Por ejemplo, reciben notificaciones sobre las solicitudes de una página .aspx. El ciclo de vida de la aplicación para el modo Clásico es el mismo que el ciclo de vida de ASP.NET en IIS 6.0. Para obtener más información, consulte Descripción general del ciclo de vida de la aplicación ASP.NET para IIS 5.0 y 6.0. Si una aplicación que se ejecuta en modo clásico contiene un controlador que requiere un mapa de scripts para manejar una extensión personalizada en IIS, debe registrar el controlador tanto en el grupo httpHandler como en el grupo de manejadores. Asigna la extensión personalizada de nombre de archivo a la extensión ASP.NET ISAPI (Aspnet_isapi.dll) especificando los módulos y los atributos scriptProcessor en el elemento del manejador. Estos atributos especifican que el módulo que define el controlador es una extensión ISAPI y especifican la ruta de esa extensión. Así es como IIS 7.0 en modo clásico proporciona compatibilidad con versiones anteriores de IIS. Sin embargo, si ejecuta la aplicación en modo integrado, debe eliminar los módulos y los atributos scriptProcessor. Para obtener más información, vea Cómo: Configurar una extensión de controlador HTTP en IIS. Cuando mueve una aplicación web de IIS 6.0 al modo clásico, no se garantiza que funcione en modo integrado sin cambios. Si cambia una aplicación del modo Clásico al modo Integrado (y cambia los módulos y controladores personalizados), es posible que deba realizar cambios adicionales para que la aplicación se ejecute correctamente en el modo Integrado. La siguiente sección de este tema explica cómo mover una aplicación al modo integrado de IIS 7.0.

modo integrado de aplicaciones web que no incluyen módulos o controladores personalizados por lo general trabajar sin cambios en el modo integrado en IIS 7.0. Las aplicaciones web que dependen de módulos o controladores personalizados requieren los siguientes pasos para permitir que la aplicación se ejecute en modo integrado: Registre módulos y controladores personalizados en la sección system.webServer del archivo Web.config utilizando uno de los métodos descritos en Migración de un archivo de configuración web a la sección Modo integrado más adelante en este tema. Defina manejadores de eventos para HttpApplication request eventos de canalización como BeginRequest y EndRequest solo en el método Init del módulo personalizado. Asegúrese de haber solucionado los problemas descritos en la sección "Diferencias conocidas entre modo integrado y modo clásico" de Actualización de aplicaciones ASP.NET a IIS 7.0: diferencias entre el modo integrado de IIS 7.0 y el modo clásico. Los módulos que implementan la interfaz IHttpModule se denominan módulos de código administrado porque se crean utilizando .NET Framework. Los módulos de código administrado se pueden registrar en el nivel del servidor o en el nivel de la aplicación. Los módulos de código nativo son DLL (código no administrado) que están registrados solo a nivel del servidor. Las funciones principales de ASP.NET, como el estado de la sesión y la autenticación de formularios, se implementan como módulos administrados en modo integrado. Cuando mueve una aplicación del modo Clásico al modo Integrado, puede dejar módulos personalizados y registros de manejador para el modo Clásico, o puede eliminarlos. Si no elimina los registros de httpModules y httpHandlers que se usan en el modo Clásico, debe establecer el atributo validateIntegratedModeConfiguration del elemento de validación en falso para evitar errores. El elemento de validación es un elemento hijo del elemento system.webServer. Para obtener más información, consulte la sección "Deshabilitar el mensaje de migración" en la integración de ASP.NET con IIS 7.0.