asp.net - ¿Cuál es la diferencia entre el modo de canalización ''clásico'' e ''integrado'' en IIS7?

iis modo integrado (5)

Anoche estaba implementando una aplicación MVC de ASP.NET y descubrí que es menos trabajo implementar con IIS7 configurado en modo integrado. Mi pregunta es ¿cuál es la diferencia? ¿Y cuáles son las implicaciones de usar uno u otro?

IIS 6.0 y versiones anteriores:

ASP.NET integrado con IIS a través de una extensión ISAPI, una API C (API basada en lenguaje de programación C) y expuso su propia aplicación y modelo de procesamiento de solicitudes.

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

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

La principal limitación de este modelo fue que los servicios proporcionados por los módulos ASP.NET y el código de aplicación ASP.NET personalizado NO estaban disponibles para solicitudes que no fueran ASP.NET

¿Qué es un mapa de guiones?

Los mapas de secuencias de comandos se utilizan para asociar extensiones de archivo con el controlador ISAPI que se ejecuta cuando se solicita ese tipo de archivo. El mapa de secuencias de comandos también tiene una configuración opcional que verifica que el archivo físico asociado con la solicitud existe antes de permitir que se procese la solicitud

Un buen ejemplo se puede seen here

IIS 7 y superior

IIS 7.0 y posteriores han sido rediseñados desde cero para proporcionar una nueva ISAPI basada en API de C ++.

IIS 7.0 y superior integran el tiempo de ejecución de ASP.NET con la funcionalidad central del servidor web, proporcionando un flujo de procesamiento de solicitud unificado (único) que se expone a los componentes nativos y administrados 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 proporcionan procesamiento de solicitudes en todas las etapas. Esta es la razón por la que los tipos de contenido NON ASP.NET ( .html, archivos estáticos) pueden ser manejados por módulos .NET.

Puede crear nuevos módulos administrados ( IHttpModule ) que tienen la capacidad de ejecutar para todo el contenido de la aplicación, y proporcionó un conjunto mejorado de servicios de procesamiento de solicitudes a su aplicación.
Agregar nuevos manejadores administrados ( IHttpHandler )

Modo de grupo de aplicaciones integrado
Cuando un grupo de aplicaciones está en modo Integrado, puede aprovechar la arquitectura integrada de procesamiento de solicitudes de IIS y ASP.NET. Cuando un proceso de trabajo en un grupo de aplicaciones recibe una solicitud, la solicitud pasa a través de una lista ordenada de eventos. Cada evento llama a los módulos nativos y administrados necesarios para procesar partes de la solicitud y generar la respuesta.
Hay varios beneficios al ejecutar grupos de aplicaciones en modo Integrado. Primero, los modelos de procesamiento de solicitudes de IIS y ASP.NET se integran en un modelo de proceso unificado. Este modelo elimina los pasos que se duplicaron previamente en IIS y ASP.NET, como la autenticación. Además, el modo integrado permite 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 modo Clásico, IIS 7.0 maneja las solicitudes como en el modo de aislamiento del proceso de trabajo de IIS 6.0. Las solicitudes de ASP.NET primero pasan por los pasos de procesamiento nativo en IIS y luego se enrutan a Aspnet_isapi.dll para procesar el código administrado en el tiempo de ejecución administrado. Finalmente, la solicitud se enruta de vuelta 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 la autorización. Además, las funciones de código administrado, como la autenticación de formularios, solo están disponibles para las aplicaciones ASP.NET o para las que tiene asignadas secuencias de comandos a todas las solicitudes que debe manejar aspnet_isapi.dll.
Asegúrese de probar la compatibilidad de sus aplicaciones existentes en el modo integrado antes de actualizar un entorno de producción a IIS 7.0 y de asignar aplicaciones a los grupos de aplicaciones en el modo integrado. Solo debe agregar una aplicación a un grupo de aplicaciones en el modo Clásico si la aplicación no funciona en el modo Integrado. Por ejemplo, su aplicación podría depender de 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: ¿Cuál es la diferencia entre DefaultAppPool y Classic .NET AppPool en IIS7?

Fuente original: Introducción a la arquitectura IIS

El modo clásico (el único modo en IIS6 e inferior) es un modo en el que IIS solo funciona con 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 como una caja negra (y solo cuando es necesario entregar 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 modo nuevo en IIS7 en el que la interconexión de IIS está estrechamente integrada (es decir, es la misma) que la canalización de solicitudes de ASP.NET. ASP.NET puede ver cada solicitud que desee y manipular las cosas en el camino. ASP.NET ya no se trata como un complemento externo. Está completamente mezclado e integrado en IIS. En este modo, los HttpModule ASP.NET tienen prácticamente la misma potencia que tendría un filtro ISAPI y el HttpHandler ASP.NET puede tener una capacidad casi equivalente a la de una extensión ISAPI. En este modo, ASP.NET es básicamente una parte de IIS.

En el modo clásico, IIS funciona con las extensiones ISAPI y los 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 no obtiene beneficios adicionales de las características de IIS 7.x.

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

Modo clásico Por lo general, mover una aplicación web de IIS 6.0 al modo clásico de IIS 7.0 solo requiere que coloque la aplicación en un grupo de aplicaciones que se ejecuta en el modo clásico. Por ejemplo, cuando instala IIS 7.0 con, de forma predeterminada, el servidor web está configurado para funcionar 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 el modo Clásico, use la aplicación Classic.NETAppPool o cree un nuevo grupo de aplicaciones que esté configurado para ejecutarse en el modo Clásico. Para obtener información sobre cómo crear un grupo de aplicaciones, consulte 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 se notifica solo sobre las solicitudes de canalización que son manejadas por el tiempo de ejecución de ASP.NET. Por ejemplo, se les notifica 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 la 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 script para manejar una extensión personalizada en IIS, debe registrar el controlador tanto en el grupo httpHandler como en el grupo de controladores. Asigna la extensión de nombre de archivo personalizada a la extensión ISAPI de ASP.NET (Aspnet_isapi.dll) especificando los módulos y los atributos del procesador de secuencias de comandos en el elemento controlador. 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 el 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 del procesador de secuencias de comandos. 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 tenga que 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.

Las aplicaciones web de modo integrado que no incluyen módulos o controladores personalizados generalmente funcionarán sin cambios en el modo integrado en IIS 7.0. Las aplicaciones web que dependen de módulos o manejadores personalizados requieren los siguientes pasos para permitir que la aplicación se ejecute en modo Integrado: Registre los módulos y manejadores personalizados en la sección system.webServer del archivo Web.config usando uno de los métodos descritos en Migración una sección del archivo de configuración web al modo integrado más adelante en este tema. Defina los controladores de eventos para eventos de canalización de solicitud HttpApplication como BeginRequest y EndRequest solo en el método Init del módulo personalizado. Asegúrese de haber solucionado todos los problemas descritos en la sección "Diferencias conocidas entre el modo integrado y el modo clásico" de Actualización de aplicaciones ASP.NET a IIS 7.0: diferencias entre el modo integrado y el modo clásico de IIS 7.0. Los módulos que implementan la interfaz IHttpModule se conocen como 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 se registran solo en el 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 el modo Integrado. Cuando mueve una aplicación del modo Clásico al modo Integrado, puede dejar módulos personalizados y registros de manejadores para el modo Clásico, o puede eliminarlos. Si no elimina los registros 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 secundario del elemento system.webServer. Para obtener más información, consulte la sección "Deshabilitar el mensaje de migración" en Integración de ASP.NET con IIS 7.0.