Actualización de ASP.NET 1.1 a IIS 7.0 en Windows Vista y Windows Server 2008
Por el equipo de IIS
Introducción
Para los desarrolladores de aplicaciones de ASP.NET que pasan al sistema operativo Windows Vista™ u otra versión posterior del sistema operativo Windows, IIS 7.0 o versiones posteriores, representa un avance significativo con respecto a las versiones anteriores de IIS. El modo integrado de IIS ofrece mayor seguridad y nuevas posibilidades de aplicación, entre otras mejoras.
La mayoría de los desarrolladores que pasan a la actualización de Windows Vista desde el sistema operativo Microsoft Windows® XP actualizan sus aplicaciones ASP.NET en el proceso. O instalan en Windows Vista las aplicaciones ASP.NET desarrolladas en otros sistemas operativos Windows.
En este documento se detallan los pasos importantes de configuración posteriores a la instalación y a la actualización que se deben realizar para que las aplicaciones funcionen en el nuevo sistema operativo. Describe los cambios entre el modo clásico y el modo integrado de IIS que afectan a las aplicaciones de ASP.NET y cómo solucionar estos problemas conocidos.
Una de las mejoras significativas de IIS 7.0 y versiones posteriores es una característica de canalización integrada que permite a las aplicaciones web usar una única canalización de procesamiento de solicitudes desde aplicaciones de código administrado o no administrado. Además, el nuevo modelo de canalización reduce el comportamiento redundante que resulta de dos implementaciones independientes de la misma característica.
Por ejemplo, en versiones anteriores, IIS y ASP.NET implementaban canalizaciones de solicitudes independientes que no compartían el acceso a eventos y módulos del controlador. La autenticación se realizaba de forma independiente dentro de cada canalización. En el nuevo modelo, la autenticación se puede realizar una sola vez para IIS y ASP.NET.
Entre otras ventajas de esta integración se incluyen:
- Servicios de ASP.NET como la autenticación de formularios y roles que funcionan con tipos de contenido de IIS, por ejemplo, páginas ASP estáticas y clásicas.
- La funcionalidad de IIS se extiende con código administrado y con los módulos de canalización de ASP.NET, en lugar de solo con extensiones ISAPI o CGI.
- Solución de problemas simplificada resultante de la integración del seguimiento de eventos y el registro de errores.
- Uso compartido de la configuración de la aplicación entre ASP.NET e IIS.
En este artículo se examinan los problemas de compatibilidad de las aplicaciones ASP.NET que migran de versiones anteriores de IIS a IIS 7.0 y versiones posteriores, y se centra específicamente en las diferencias relacionadas con la transición del modo clásico al uso de la canalización integrada del modo integrado.
Para obtener una información general completa sobre las características y ventajas de la integración de ASP.NET e IIS, consulte el artículo Integración de ASP.NET con IIS 7.0 y versiones posteriores.
Actualización desde versiones anteriores de IIS a Windows Vista
El gráfico siguiente muestra la disponibilidad de IIS 7.0 en las versiones disponibles de Windows Vista:
| Versión de Windows Vista | Disponibilidad de IIS 7.0 |
|---|---|
| Home Basic | N |
| Home Premium | Y |
| Negocio | Y |
| Ultimate | Y |
Escenarios de actualización de ASP.NET en Windows Vista
En la tabla siguiente se proporciona un breve esquema de las rutas de actualización admitidas para ASP.NET en las versiones anteriores de los sistemas operativos Windows para ASP.NET en Windows Vista. Donde se indican los problemas, consulte las secciones siguientes para más información sobre las restricciones y limitaciones de actualización.
En la tabla también se muestra que las actualizaciones de las versiones del sistema operativo de servidor a las versiones del sistema operativo cliente no están disponibles. En su lugar, debe realizar una instalación limpia de Vista en un equipo con un sistema operativo de servidor instalado actualmente.
| Sistema operativo | Versión de IIS | Versión de .NET Framework | Consideraciones generales a la hora de actualizar a Windows Vista o IIS 7.0 |
|---|---|---|---|
| Windows 2000 Server | IIS 5.0 | 1.0, 1.1, 2.0 | La actualización a Windows Vista no está disponible. |
| Windows 2000 Professional | IIS 5.0 | 1.0, 1.1, 2.0 | Se requiere la instalación limpia del sistema operativo. |
| Windows Server 2003 | IIS 6,0 | 1.0, 1.1, 2.0 | La actualización a Windows Vista no está disponible. |
| Windows XP Home Edition | N/D | 1.0, 1.1, 2.0 | Windows XP Home Edition no incluía IIS. Los usuarios pueden decidir instalar IIS 7.0 o versiones posteriores desde cero en Windows Vista. |
| Windows XP Professional | IIS 5,1 | 1.0 | .NET Framework 1.0 no se admite en Windows Vista. Las aplicaciones de ASP.NET 1.0 se deben actualizar al menos a ASP.NET 1.1 (se recomienda ASP.NET 2.0). |
| 1.1 | Se requiere configuración manual después de la actualización (consulte más adelante en este artículo). | ||
| 2.0 | Se debe seleccionar ASP.NET en las opciones de configuración de IIS después de una actualización para que ASP.NET 2.0 se configure en modo integrado. | ||
| Windows XP Tablet PC | IIS 5,1 | 1.0 | .NET Framework 1.0 no se admite en Windows Vista. Las aplicaciones de ASP.NET 1.0 se deben actualizar al menos a ASP.NET 1.1 (se recomienda ASP.NET 2.0). |
| 1.1 | Se requiere configuración manual después de la actualización (consulte más adelante en este artículo). | ||
| 2.0 | Se debe seleccionar ASP.NET en las opciones de configuración de IIS después de una actualización para que ASP.NET 2.0 se configure en modo integrado. | ||
| Windows XP Professional x64 | IIS 5,1 | 1.1, 2.0 | Se requiere la instalación limpia del sistema operativo. |
Configuración de la aplicación posterior a la instalación
Inmediatamente después de una instalación o actualización a Windows Vista, los usuarios deben realizar pasos de configuración adicionales para permitir que las aplicaciones funcionen. La configuración posterior a la instalación depende de la versión de ASP.NET que usa cada aplicación.
Configuración de aplicaciones de ASP.NET 1.1
Antes de instalar .NET Framework 1.1 (necesario si ejecuta aplicaciones de ASP.NET 1.1), los usuarios deben realizar los dos pasos siguientes para habilitar las aplicaciones ASP.NET:
Procedimiento
Cada grupo de aplicaciones de IIS que ejecuta una aplicación ASP.NET se debe configurar explícitamente mediante la versión de .NET Framework que coincida con la versión de ASP.NET usada para la aplicación. Solo puede ejecutar una versión de ASP.NET por cada grupo de aplicaciones, por lo que debe usar grupos de aplicaciones independientes para cada versión de ASP.NET.
En la consola del Administrador de IIS, abra Grupos de aplicaciones y haga clic con el botón derecho en un grupo de aplicaciones y seleccione Configuración básica. En el cuadro de diálogo Editar grupo de aplicaciones que se muestra en la figura 1, seleccione la versión de .NET Framework que coincida con las aplicaciones configuradas en el grupo de aplicaciones y, a continuación, haga clic en Aceptar.
Figura 1: Editar grupo de aplicaciones
Uso de ASP.NET 1.1 en modo clásico
ASP.NET 1.1 usa una extensión ISAPI de IIS cuando se ejecuta en modo clásico, que es la configuración predeterminada para ASP.NET posterior a la instalación o actualización (tenga en cuenta que ASP.NET 2.0 también se puede ejecutar en modo integrado en Windows Vista, ya que no requiere una extensión ISAPI).
Debe permitir explícitamente la versión de ASP.NET que usen las aplicaciones para ejecutarse mediante la configuración de restricciones de ISAPI y CGI en la consola de administración de IIS. Abra el Administrador de IIS y seleccione Restricciones de ISAPI y CGI. En la página Restricciones de ISAPI y CGI, seleccione cada versión de ASP.NET establecida como "No permitida" en la columna Restricción y haga clic en el vínculo Permitir en el lado derecho de la página para cambiar la configuración a Permitido.
En la figura 2 se muestra un ejemplo de la página Restricciones de ISAPI y CGI con la versión del ensamblado Aspnet_isapi.dll usado para la versión ASP.NET 1.1 seleccionada. En la ilustración, la configuración de esta extensión ISAPI debe cambiarse de No permitida a Permitida.
Figura 2: Lista de restricciones de ISAPI y CGI
Configuración de aplicaciones de ASP.NET 2.0
.NET Framework 2.0 se instala durante la instalación de Windows Vista y, por tanto, ASP.NET 2.0 ya está presente en el servidor después de la instalación. Sin embargo, para completar la configuración de ASP.NET en Vista para aplicaciones de ASP.NET 2.0, los usuarios deben realizar los dos pasos siguientes:
Paso 1
En el Administrador de paquetes de Windows Vista (Panel de control\Programas y características\Activar o desactivar las características de Windows), seleccione ASP.NET como se indica en la figura 3 y haga clic en Aceptar.
Nota:
Si ASP.NET ya está instalado en el equipo antes de este paso, seleccionar ASP.NET de esta manera garantiza que se completen los pasos de configuración adicionales.
Figura 3: Instalación de Windows Vista: características de Windows
Paso 2
Cada grupo de aplicaciones de IIS que ejecuta una aplicación ASP.NET se debe configurar explícitamente mediante la versión de .NET Framework que coincida con la versión de ASP.NET usada para la aplicación. Solo puede ejecutar una versión de ASP.NET por cada grupo de aplicaciones, por lo que debe usar grupos de aplicaciones independientes para cada versión de ASP.NET.
En el Administrador de IIS, abra Grupos de aplicaciones y haga clic con el botón derecho en un grupo de aplicaciones y seleccione Configuración básica. En el cuadro de diálogo Editar grupo de aplicaciones que se muestra en la figura 4, seleccione la versión de .NET Framework que coincida con las aplicaciones configuradas en el grupo de aplicaciones y haga clic en Aceptar.
Figura 4: Grupo de aplicaciones y modo integrado
Configuración del grupo de aplicaciones
Cuando se actualizan aplicaciones ASP.NET de versiones anteriores de sistemas operativos Windows a Windows Vista, las aplicaciones se configuran en grupos de aplicaciones en función de la configuración de aislamiento de aplicaciones de IIS de la manera siguiente:
| Configuración de aislamiento de IIS antes de actualizar | Grupo de aplicaciones de IIS | Identidad del grupo de aplicaciones de IIS |
|---|---|---|
| Bajo | AppPool bajo | NT AUTHORITY\NETWORK SERVICE |
| Media | AppPool medio | IWAM_<nombre de la máquina> |
| Alto | Las aplicaciones se configuran en un grupo de aplicaciones que coincide con el nombre de la aplicación. | IWAM_<nombre de la máquina> |
ASP.NET v1.0 no se admite en Windows Vista.
.NET Framework 1.0 no se admite en Windows Vista y, por lo tanto, las aplicaciones de ASP.NET 1.0 deben actualizarse al menos a ASP.NET 1.1. Se recomienda encarecidamente actualizar las aplicaciones de ASP.NET 1.0 a ASP.NET 2.0 para aprovechar las mejores características de rendimiento y mantenimiento que se encuentran en las versiones más recientes de ASP.NET.
Controladores HTTP
En una actualización a IIS 7.0 y versiones posteriores en Windows Vista, solo se actualizan los controladores HTTP previamente configurados en el nivel global. Los controladores configurados en el nivel de sitio no se actualizan.
Compatibilidad con la ejecución en paralelo
Puede ejecutar aplicaciones desarrolladas en diferentes versiones de ASP.NET (por ejemplo, 1.1 y 2.0) en paralelo en IIS. Debe configurar aplicaciones en un grupo de aplicaciones de IIS. Este grupo debe configurarse para la versión de ASP.NET para la que se desarrolló la aplicación. Solo puede configurar una versión de ASP.NET por grupo de aplicaciones.
.NET Framework 1.1 requiere la configuración de WoW 64 en Windows Vista de 64 bits
ASP.NET no se configura correctamente si .NET Framework 1.1 está instalado en versiones de 64 bits de Windows Vista. Después de instalar .NET Framework 1.1 en versiones de 64 bits de Windows Vista, debe configurar manualmente las aplicaciones para que se ejecuten con WOW 64 en el nivel global mediante la herramienta de administración de IIS.
Configuración del modo de canalización que una aplicación usa
IIS está configurado para usar el nuevo modo integrado de las nuevas aplicaciones. Este es el comportamiento predeterminado. El modo de canalización se configura mediante la configuración del grupo de aplicaciones. Cambie esta configuración mediante:
- La herramienta de administración de IIS
- La herramienta de línea de comandos APPCMD.EXE
- Mediante la edición del archivo de configuración de la aplicación con un editor de texto.
Si va a actualizar un equipo existente a IIS 7.0 o versiones posteriores, las aplicaciones se configuran para ejecutarse en modo clásico de manera predeterminada. El modo clásico proporciona compatibilidad con las aplicaciones que tienen dependencias específicas en la implementación de la canalización HTTP en versiones anteriores de IIS.
Sin embargo, si va a importar una aplicación existente a un equipo que ejecuta IIS 7.0 y versiones posteriores, y va a copiar el sitio web, el modo de canalización usado viene determinado por la configuración del grupo de aplicaciones en el que se configura la aplicación para ejecutarse.
Por ejemplo, si copia la aplicación en el equipo y la configura para que se ejecute en el grupo de aplicaciones predeterminado, se ejecuta mediante la configuración del grupo de aplicaciones que, de manera predeterminada, está configurado en modo integrado. Para cambiar el modo de canalización de la aplicación, cambie la configuración del grupo de aplicaciones predeterminado o cree un nuevo grupo de aplicaciones con la configuración que desee.
Obtenga más información sobre cómo configurar una aplicación existente para que use el modo integrado en el artículo Integración de ASP.NET con IIS 7.0 y versiones posteriores, en la sección titulada "Migración de aplicaciones de ASP.NET a IIS 7.0 y versiones posteriores: Modo integrado". Esto proporciona instrucciones para cambiar las opciones de configuración de la aplicación.
Compatibilidad
Los módulos de canalización de ASP.NET desarrollados en versiones anteriores de IIS y configurados posteriormente para que usen el modo integrado con IIS 7.0 y versiones posteriores, pueden experimentar diferencias en el comportamiento u otros problemas de compatibilidad. Estos problemas se deben a las diferencias de arquitectura entre la canalización de las versiones anteriores de IIS y el diseño modular de IIS 7.0 y versiones posteriores, y la canalización HTTP integrada.
En las secciones restantes de este artículo se describen los posibles problemas de compatibilidad que pueden surgir y se incluyen soluciones alternativas sugeridas. Si una solución alternativa sugerida no es práctica a la hora de implementarse, configure la aplicación para que se ejecute en modo clásico y evitar el problema de compatibilidad.
Diferencias conocidas entre el modo integrado y el modo clásico
A continuación se proporciona una lista de problemas conocidos entre los dos modos. Lea esta lista atentamente.
En el modo integrado, no se llama a Application_OnError para las excepciones que se producen en HttpApplication::Init
En el modo integrado, las excepciones que se producen durante la inicialización de una aplicación o módulo no se pueden interceptar mediante el evento Application.Error.
Además, las aplicaciones que usan Server.ClearError para recuperarse de errores no pueden borrar errores durante la inicialización de la aplicación. Esto es para evitar que una aplicación omita un error durante la inicialización. Las aplicaciones que registran información de error para cada excepción que se produce no podrán registrar los errores que se producen durante la inicialización de la aplicación, aunque estos errores se notifiquen mediante eventos web y respuestas HTTP.
Si una aplicación requiere la implementación de este control de excepciones durante la inicialización, debe ejecutarse en modo clásico en lugar de en modo integrado.
Server.ClearError en EndRequest no borra el mensaje de excepción en modo integrado
En el modo integrado, llamar a Server.ClearError en EndRequest no borra la respuesta de excepción si se ha producido una excepción anteriormente en el procesamiento de solicitudes. Las aplicaciones que borran el mensaje de excepción en EndRequest no pueden eliminar la salida de la excepción de la respuesta.
Si una aplicación requiere la implementación de este control de excepciones durante EndRequest, debe ejecutarse en modo clásico en lugar de en modo integrado.
Las aplicaciones en modo integrado pueden escribir en una respuesta en EndRequest después de dar formato a una excepción y escribirla en la respuesta.
En el modo integrado, es posible escribir y mostrar una respuesta adicional escrita después de que se haya producido una excepción.
Esto no se produce en el modo clásico. Si se produce un error durante la solicitud y la aplicación escribe en la respuesta en EndRequest después de que se haya producido la excepción, se mostrará la información de respuesta escrita en EndRequest. Esto solo afecta a las solicitudes que incluyen excepciones no controladas.
Para evitar escribir en la respuesta después de una excepción, una aplicación debe comprobar HttpContext.Error o HttpResponse.StatusCode antes de escribir en la respuesta.
En el modo integrado, ASP.NET ya no suprime el tipo de contenido cuando la respuesta está vacía.
En el modo integrado, los controladores de ASP.NET generan encabezados de tipo de contenido cuando así lo establece explícitamente un módulo, incluso si la respuesta está vacía. Algunas aplicaciones generan un tipo de contenido para respuestas vacías. Si lo desea, modifique las aplicaciones para que eliminen explícitamente el encabezado Tipo de contenido estableciéndolo en NULL.
Identidad de Windows diferente en la autenticación de formularios
Cuando una aplicación usa la autenticación de formularios y se permite el acceso anónimo, la identidad del modo integrado difiere de la identidad del modo clásico de las maneras siguientes:
- ServerVariables["LOGON_USER"] se rellena.
- Request.LogognUserIdentity usa las credenciales de la cuenta [NT AUTHORITY\NETWORK SERVICE] en lugar de la cuenta [NT AUTHORITY\INTERNET USER].
Este comportamiento se produce porque la autenticación se realiza en una sola fase en modo integrado. Por el contrario, en el modo clásico, la autenticación se produce primero con IIS mediante acceso anónimo y, a continuación, con ASP.NET mediante la autenticación de formularios. Por lo tanto, el resultado de la autenticación siempre es un usuario único: el usuario de autenticación de formularios. AUTH_USER/LOGON_USER devuelve este mismo usuario porque las credenciales de usuario de autenticación de formularios se sincronizan entre IIS y ASP.NET.
Un efecto secundario es que LOGON_USER, HttpRequest.LogonUserIdentity y la suplantación ya no pueden acceder a las credenciales de usuario anónimo que IIS habría autenticado mediante el modo clásico.
El evento Authentication_OnAuthenticate predeterminado no se genera en el modo integrado
En el modo integrado, el evento DefaultAuthenticationModule.Authenticate ya no se genera. En el modo clásico, este evento se genera cuando no se ha producido ninguna autenticación. En el modo integrado, una aplicación que establece authentication mode=None y se suscribe al evento DefaultAuthentication.Authenticate, recibirá una excepción que indica que esta característica no se admite en modo integrado. Los esquemas de autenticación que se basan en este patrón no funcionarán.
Para solucionar este cambio, las aplicaciones en modo integrado pueden suscribirse a AuthenticateRequest en su lugar.
En el modo integrado, Request.RawUrl contiene la nueva cadena de consulta después de llamar a RewritePath.
En el modo integrado, después de llamar a RewritePath en una dirección URL con una nueva cadena de consulta, la propiedad Request.RawUrl contiene la nueva cadena de consulta. En el modo clásico, contiene la cadena de consulta anterior.
Para solucionar este cambio, reescriba la aplicación para que no dependa del comportamiento anterior.
La autenticación de credenciales de Passport Network no se admite en Windows Vista
La funcionalidad de credenciales de Passport Network se ha eliminado de Windows Vista y del sistema operativo Microsoft Windows Server® 2008, por lo que las aplicaciones de autenticación de credenciales de Passport Network no funcionan de manera predeterminada en ISAPI ni en el modo integrado.
El módulo PassportAuthentication no forma parte de la canalización integrada.
En el modo integrado, el módulo PassportAuthentication de ASP.NET se elimina de la canalización de forma predeterminada. Si una aplicación lo usa, se puede volver a agregar a la canalización. Como se ha indicado anteriormente, la funcionalidad subyacente de credenciales de Passport Network se ha eliminado de Windows Vista y del sistema operativo Microsoft Windows Server® 2008, por lo que las aplicaciones de autenticación de credenciales de Passport Network no funcionan de manera predeterminada en ISAPI ni en el modo integrado.
IIS 7.0 y versiones posteriores rechazan los vales de autenticación de formularios grandes y válidos (longitud <= 4096 bytes) presentes en la cadena de consulta.
IIS rechaza las solicitudes con vales grandes de ASP.NET sin cookies, como los usados en la autenticación de formularios, el estado de sesión y el identificador anónimo que en total superan los 4096 bytes. Por motivos de seguridad, esto evita las vulnerabilidades de seguridad por desbordamiento de búfer que usan cadenas de consulta grandes. Las aplicaciones que almacenan datos personalizados o que usan nombres de usuario muy grandes en vales de autenticación de formularios pueden ver que las solicitudes se rechazan porque las cadenas de consulta son demasiado grandes.
Para cambiar este comportamiento, ajuste el tamaño máximo de la cadena de consulta en la sección de configuración del filtrado de solicitudes de IIS.
En el modo integrado, el tiempo de espera de solicitud de ASP.NET se aplica varias veces durante la solicitud, lo que permite que esta se ejecute durante más tiempo.
En el modo integrado, el tiempo de espera de ejecución de la solicitud administrada se restablece para cada nueva transición de la canalización. Esto significa que la solicitud puede usar hasta (tiempo de espera *(el número de notificaciones de módulo)), siempre que cualquier tiempo de espera único no supere el tiempo máximo establecido para un tiempo de espera.
Es posible que las solicitudes lentas no se anulen o que tarden mucho más tiempo en anularse, en función del número de módulos de ASP.NET y de la combinación de estos módulos. Evite este comportamiento reduciendo el período del tiempo de espera.
La configuración de seguimiento no se transfiere a la página de destino Server.Transfer
El modo integrado no admite la transferencia de la configuración de seguimiento al destino de una operación Server.Transfer.
El método Httpcontext.Current.Response.Write() no puede funcionar en Application_Onstart()
En el modo integrado, una aplicación no puede llamar a Http.Current.Response.Write() en un método Application_Onstart().
Si se accede a HttpRequest.LogonUserIdentity antes que PostAuthenticateRequest se produce una excepción.
En el modo integrado, la propiedad HttpRequest.LogonUserIdentity producirá una excepción si se accede a ella antes que PostAuthenticateRequest. Si un módulo accede a esta propiedad antes que PostAuthenticateRequest, se produce una excepción.
Para evitar este comportamiento: no acceda a esta propiedad en la aplicación; o bien, acceda después de que PostAuthenticateRequest se haya completado.
En el modo integrado, los módulos de ASP.NET recibirán la primera solicitud no autenticada a IIS 7.0 y versiones posteriores cuando la autenticación anónima esté deshabilitada.
En el modo integrado, cuando se usa un esquema de autenticación de IIS distinto de la autenticación anónima, la primera solicitud del cliente que no contiene las credenciales necesarias es visible para los módulos de ASP.NET en las fases BeginRequest y AuthenticateRequest.
En comparación, en el modo clásico, una aplicación ASP.NET no vería dicha solicitud porque IIS la rechazaría con un error 401 antes de que ASP.NET tuviera la oportunidad de procesarla.
Esto significa que los módulos de ASP.NET verán una solicitud adicional en las fases BeginRequest y AuthenticateRequest. La solicitud aparece en eventos web y en cualquier registro personalizado realizado en BeginRequest o EndRequest.
ASP.NET no puede suplantar la identidad de cliente hasta la ejecución de PostAuthenticateRequest
En el modo integrado, ASP.NET no suplantará al cliente hasta la ejecución de PostAuthenticateEvent si la suplantación de cliente está habilitada para una aplicación mediante el archivo Web.config de esta o en Machine.config.
Además, cuando la suplantación de cliente está habilitada, los módulos que se ejecutan en los eventos BeginRequest y AuthenticateRequest se ejecutan con la identidad del proceso en lugar de con la identidad del usuario autenticado. Esto no debe ser un problema porque los módulos rara vez acceden a los recursos de estos eventos, ya que el usuario autenticado aún no se ha establecido.
Sin embargo, si esto se hace, la identidad de proceso se usa para acceder a los recursos.
Debido a la posible elevación de derechos de usuario que este cambio puede provocar, IIS produce una excepción cuando la suplantación de cliente está habilitada. Esto indica que la aplicación debe pasarse al modo clásico o que este error debe desactivarse si se puede confirmar que se tiene acceso a los recursos en los eventos BeginRequest o AuthenticateRequest.
El encabezado Content-Type no se genera cuando el juego de caracteres y el tipo de contenido están establecidos en una cadena vacía.
HTTP.sys ya no genera el encabezado Content-Type si se establece explícitamente en String.Empty. Las aplicaciones cuyos clientes dependen de tener un encabezado Content-Type vacío pueden verse afectados por este cambio.
En el modo integrado, se generan eventos sincrónicos y asincrónicos para cada módulo antes de que se ejecute el módulo siguiente.
En el modo integrado, se generarán eventos sincrónicos y asincrónicos para cada módulo antes de que el servidor se traslade al módulo siguiente.
Esto difiere del modo clásico en el que todas las notificaciones de módulo asincrónicas se ejecutan primero, seguidas de todas las notificaciones sincrónicas. No debería haber ningún efecto en las aplicaciones a menos que exista una dependencia de la ordenación (consulte "La ordenación de módulos se invierte para PreSendRequestHeaders y PreSendRequestContent al usar el modo integrado" en otra parte de este documento).
Los encabezados de respuesta se eliminan en el modo integrado después de llamar a ClearHeader en un IHttpModule personalizado
En el modo integrado, llamar a ClearHeaders no genera automáticamente encabezados predeterminados. En vez de eso, las aplicaciones que llaman a ClearHeaders para devolver los encabezados al estado predeterminado de una página de .aspx borran todos los encabezados de respuesta.
No se admite el uso de la autenticación de Windows y de formularios conjuntamente en el modo integrado
En el modo integrado, no se admite el establecimiento de Impersonate=true y el uso de la autenticación de formularios y se producirá un error o un comportamiento incorrecto.
En el modo integrado, IIS 7.0 y versiones posteriores siempre rechazan nuevas líneas en los encabezados de respuesta (incluso si ASP.NET enableHeaderChecking está establecido en false)
En el modo integrado, se produce una excepción al intentar establecer un encabezado de respuesta en un valor que contenga \r o \n. En el modo clásico, este valor se codifica de manera predeterminada y se pasa si la codificación del encabezado está desactivada. Por motivos de seguridad, las aplicaciones no deben intentar escribir nuevas líneas sin codificar en los valores de encabezado.
Los eventos PreSendRequestHeaders y PreSendRequestContent se generarán juntos para cada módulo.
En el modo integrado, los módulos que se suscriben a los eventos PreSendRequestHeaders y PreSendRequestContent se notifican conjuntamente para los eventos PreSendRequestHeaders y PreSendRequestContent.
Por ejemplo, una aplicación puede interrumpirse si el módulo A tiene una dependencia en que el módulo B se ejecute primero en PreSendRequestHeaders, antes de que se ejecute el módulo A para PreSendRequestContent, como cuando el módulo B modifica algún estado de solicitud y el módulo A se basa en él.
El orden de los módulos se invierte para PreSendRequestHeaders y PreSendRequestContent al usar el modo integrado.
En el modo integrado, los módulos que se suscriben a PreSendRequestHeaders y PreSendRequestContent se notificarán en el orden opuesto al de su aparición en la sección. Las aplicaciones que tienen varios módulos configurados para ejecutarse en cualquiera de estos eventos pueden verse afectados por este cambio si comparten una dependencia en el orden de eventos.
Para solucionar estos problemas, cambie el orden de los módulos en la sección o ejecute la aplicación en modo clásico.
En el modo integrado, se omite la configuración de subprocesos y colas.
En el modo integrado, ASP.NET, no IIS, procesa solicitudes en los subprocesos y no usa la semántica de subprocesos o colas que se usa en el modo clásico. Debido a esta diferencia, las aplicaciones pueden experimentar un comportamiento de rendimiento o estrés diferente en el modo integrado que cuando se ejecuta en modo clásico.
Si se produce un error de archivo de configuración al usar el modo integrado, IIS, no ASP.NET, genera el mensaje de error.
En el caso de las aplicaciones que se ejecutan en modo integrado, IIS ahora lee los archivos de configuración de la aplicación. Por lo tanto, si se encuentra XML con formato incorrecto en el archivo Web.config o si hay errores de configuración en el archivo, IIS siempre genera un mensaje de error y no ASP.NET.
Dado que IIS y ASP.NET escriben los errores en diferentes formatos, el formato del mensaje de error difiere en función de si la aplicación se ejecuta en modo integrado o en modo clásico. Este es un ejemplo de un tipo de error de archivo de configuración que IIS genera: Error interno de configuración del servidor: el archivo de configuración no tiene el formato XML correcto.
En el modo integrado, las aplicaciones ASP.NET deben suscribirse a eventos de canalización durante la llamada a Init de un módulo.
Las aplicaciones ASP.NET que usan la canalización HTTP de ASP.NET podrían suscribirse a eventos de aplicación fuera de la canalización. Sin embargo, las aplicaciones ASP.NET que usan la canalización del modo integrado de IIS ahora deben suscribirse siempre a eventos durante el método Init() del módulo. En el ejemplo siguiente se muestra cómo se implementa una suscripción de eventos en Init:
Public void Init(httpApplication context)
{
Context.AuthenticateRequest += new EventHandler(this.AuthenticateUser);
}
Para más información sobre cómo crear módulos de IIS, consulte el artículo Desarrollo de un módulo mediante .NET.
Recursos adicionales
Para más información sobre cómo actualizar a IIS 7.0 y versiones posteriores en Windows Vista, consulte el artículo sobre compatibilidad de aplicaciones de IIS 7.0 en Windows Vista, titulado Requisitos de compatibilidad y características para Windows Vista.