¿Cuál es la diferencia entre el modo de tubería ‘clásico’ e ‘integrado’ en IIS7?

Estaba implementando una aplicación ASP.NET MVC anoche, 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?

El modo clásico (el único modo en IIS6 y abajo) es un modo donde IIS solo trabaja 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 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 tiene básicamente tanta potencia como un filtro ISAPI y ASP.NET HttpHandler puede tener una capacidad casi equivalente a la que podría tener una extensión ISAPI. En este modo, ASP.NET es básicamente una parte de IIS.

Modo de grupo de aplicaciones integrado

Cuando un grupo de aplicaciones está en modo integrado, puede aprovechar la architecture 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 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 varias ventajas para ejecutar grupos de aplicaciones en modo integrado. En primer lugar, los modelos de procesamiento de solicitudes de IIS y ASP.NET están 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 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 de procesos de trabajo de IIS 6.0. Las solicitudes ASP.NET primero pasan por los pasos de procesamiento nativos 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 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 autenticación y autorización. Además, las funciones del código administrado, como la autenticación de formularios, solo están disponibles para las aplicaciones ASP.NET o aplicaciones para las que el script asignó todas las solicitudes para que sean manejadas por aspnet_isapi.dll.

Asegúrese de probar sus aplicaciones existentes para la compatibilidad en 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 modo Clásico si la aplicación no funciona en modo Integrado. Por ejemplo, su aplicación puede depender de un token de autenticación pasado de IIS al tiempo de ejecución administrado y, debido a la nueva architecture 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 architecture de IIS

IIS 6.0 y versiones anteriores:

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

Esto expuso de manera efectiva dos canalizaciones de servidor (solicitud / respuesta) separadas, una para los filtros ISAPI nativos y los componentes de extensión, y otra para los componentes de la aplicación gestionada. Los componentes de ASP.NET se ejecutarían completamente dentro de la burbuja de extensión ISAPI de ASP.NET Y SÓLO 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 proporcionados por los módulos de ASP.NET y el código personalizado de la aplicación ASP.NET NO estaban disponibles para las solicitudes que no eran de ASP.NET.

¿Qué es un MAPA DE GUIÓN?

Los mapas de scripts se usan para asociar extensiones de archivos con el controlador ISAPI que se ejecuta cuando se solicita ese tipo de archivo. El mapa de scripts también tiene una configuración opcional que verifica que el archivo físico asociado a la solicitud exista 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 versiones posteriores integran el tiempo de ejecución de ASP.NET con la funcionalidad principal del servidor web, proporcionando un canal de procesamiento de solicitudes unificado (único) que está expuesto tanto a componentes nativos como 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 NON ASP.NET contiene tipos de contenido ( .html, archivos estáticos) pueden ser manejados por módulos .NET.

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

En el modo clásico, IIS trabaja directamente con extensiones ISAPI y filtros ISAPI. 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 el 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.

Modo clásico Normalmente, mover una aplicación web de IIS 6.0 a modo clásico de IIS 7.0 solo requiere que coloque 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. Todos los módulos personalizados que implementan la interfaz IHttpModule en una aplicación que se ejecuta en modo Clásico se notifican solo 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 controladores. 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.

Las aplicaciones web de modo integrado que no incluyen módulos o controladores personalizados normalmente funcionarán 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 Migrating. una sección de archivo de configuración web a modo integrado más adelante en este tema. Defina los controladores de eventos para los eventos de interconexión de solicitud HttpApplication como BeginRequest y EndRequest solo en el método Init del módulo personalizado. Asegúrese de haber abordado los problemas que se tratan 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.