iis-7 .net-4.0 asp.net-mvc-3 windows-server-2008 asp.net-4.0

Obtención de error 404.0 para la aplicación ASP.NET MVC 3 en IIS 7.0/Windows Server 2008



iis-7 .net-4.0 (6)

Estoy intentando implementar una aplicación ASP.NET MVC 3 en un servidor Windows 2008 x64 (ejecutando IIS 7.0 obviamente), e IIS no quiere que se publique correctamente el contenido. Todas las solicitudes generan un error 404.0 porque las solicitudes no coinciden con ningún controlador e IIS intenta utilizar el controlador StaticFile para atender las solicitudes. El problema parece estar relacionado con .NET 4.0, ya que tengo una aplicación MVC 2 funcionando perfectamente en un grupo de aplicaciones que está configurado para .NET 2.0 runtime.

No tuve problemas para implementar esta misma aplicación en los servidores IIS 7.5 tanto en Windows 7 como en Windows Server 2008 R2.

Antes de la implementación, el servidor 2008 no tenía instalado .NET 4.0 o ASP.NET MVC 3, así que aquí están los pasos que realicé antes de implementar la aplicación:

  1. Instalado .NET 4.0
  2. Ran aspnet_regiis.exe (de la carpeta Framework64 / v4.0.30319)
  3. Instalado ASP.NET MVC 3 utilizando el instalador de la plataforma web
  4. Applied MS actualiza KB980368 para habilitar ciertos manejadores de IIS 7.0 o IIS 7.5 para manejar solicitudes cuyas URL no terminan con un período

Las solicitudes de recursos estáticos en la aplicación (archivos JavaScript, imágenes, etc.) se realizan sin problemas, pero cualquier solicitud a una acción MVC falla con un error 404.0. Me he dado cuenta de que IIS está utilizando el controlador StaticFile para manejar estas solicitudes, lo cual es obviamente incorrecto. Los manejadores de ASP.NET 4.0 (es decir, los manejadores ExtensionlessUrl-ISAPI-4.0 *) están definidos correctamente, por lo que yo sé, así que no tengo idea de por qué / cómo la solicitud no sería manejada por uno de estos manejadores y caería todo el hasta el controlador StaticFile.

También me encontré con el siguiente artículo de la base de conocimiento de MS que menciona que debes asegurarte de que la Redirección HTTP y la Compresión de Contenido Estático estén habilitadas / instaladas en el servidor donde experimentas los errores 404. Lo revisé, y ambas funciones ya estaban habilitadas para mi servidor. Incluso traté de eliminar y volver a instalar las funciones en vano.

En este punto, estoy completamente sin ideas sobre por qué esto no funciona correctamente. Pude replicar el problema en 2 servidores diferentes de IIS 7.0. ¿Qué me estoy perdiendo?

Asegúrese de ejecutar bajo el modo integrado de IIS 7.0. Si necesita ejecutarlo en el modo clásico de IIS 7.0, debe realizar varias acciones para que las rutas funcionen. Por favor, consulte las siguientes publicaciones en el blog;

http://www.tugberkugurlu.com/archive/running-asp-net-mvc-under-iis-6-0-and-iis-7-0-classic-mode---solution-to-routing-problem

http://www.tugberkugurlu.com/archive/deployment-of-asp-net-mvc-3-rc-2-application-on-a-shared-hosting-environment-without-begging-the-hosting-company

El problema terminó siendo que mi código se basaba completamente en la funcionalidad de inicio automático que está disponible solo en IIS 7.5. Pude descubrir el problema con la ayuda de la característica de seguimiento de solicitudes fallidas en IIS, y ahora he modificado mi archivo global.asax.cs para que la aplicación se inicialice correctamente, independientemente de cómo y cuándo se cargue.

En realidad, me acabas de recordar que necesitaba solucionar este problema en un entorno aquí. Si su situación es la misma que la mía, entonces es una solución simple.

Simplemente agregue lo siguiente a su configuración web:

<system.webServer> <modules runAllManagedModulesForAllRequests="true" />

Editar : para proporcionar una explicación más detallada sobre el tema en cuestión. En mi caso, lo que sucedía era que cuando agregaba asignaciones de rutas personalizadas, IIS veía las solicitudes como solicitudes de Carpeta / Archivo estático y, por lo tanto, omitía el proceso de trabajo de ASP.NET. Esto se comporta de manera diferente en el entorno de desarrollo, en general, porque se está ejecutando en el servidor web de desarrollo, que también pasará todas las solicitudes a través del proceso .net.

Esta entrada de configuración web le dice a IIS que tiene módulos que se deben ejecutar en cada solicitud web, incluso si IIS determina que se trata de un archivo estático o una carpeta.

Mi solución, después de probar TODO:

Mala implementación, un antiguo PrecompiledApp.config estaba rondando por mi ubicación de implementación y haciendo que todo no funcionara.

Mi configuración final que funcionó:

  • IIS 7.5, Win2k8r2 x64,
  • Grupo de aplicaciones de modo integrado

  • Nada cambia en el archivo web.config ; esto significa que no hay controladores especiales para el enrutamiento. Aquí está mi instantánea de las secciones de muchas otras publicaciones de referencia. Estoy usando FluorineFX, así que tengo ese controlador añadido, pero no necesitaba ningún otro:

    <system.web> <compilation debug="true" targetFramework="4.0" /> <authentication mode="None"/> <pages validateRequest="false" controlRenderingCompatibilityVersion="3.5" clientIDMode="AutoID"/> <httpRuntime requestPathInvalidCharacters=""/> <httpModules> <add name="FluorineGateway" type="FluorineFx.FluorineGateway, FluorineFx"/> </httpModules> </system.web> <system.webServer> <!-- Modules for IIS 7.0 Integrated mode --> <modules> <add name="FluorineGateway" type="FluorineFx.FluorineGateway, FluorineFx" /> </modules> <!-- Disable detection of IIS 6.0 / Classic mode ASP.NET configuration --> <validation validateIntegratedModeConfiguration="false" /> </system.webServer>

  • Global.ashx: (método único de cualquier nota)

    void Application_Start(object sender, EventArgs e) { // Register routes... System.Web.Routing.Route echoRoute = new System.Web.Routing.Route( "{*message}", //the default value for the message new System.Web.Routing.RouteValueDictionary() { { "message", "" } }, //any regular expression restrictions (i.e. @"[^/d].{4,}" means "does not start with number, at least 4 chars new System.Web.Routing.RouteValueDictionary() { { "message", @"[^/d].{4,}" } }, new TestRoute.Handlers.PassthroughRouteHandler() ); System.Web.Routing.RouteTable.Routes.Add(echoRoute); }

  • PassthroughRouteHandler.cs - esto logró una conversión automática de http://andrew.arace.info/ a http://andrew.arace.info/# que luego sería manejado por default.aspx:

    public class PassthroughRouteHandler : IRouteHandler { public IHttpHandler GetHttpHandler(RequestContext requestContext) { HttpContext.Current.Items["IncomingMessage"] = requestContext.RouteData.Values["message"]; requestContext.HttpContext.Response.Redirect("#" + HttpContext.Current.Items["IncomingMessage"], true); return null; } }

Si está ejecutando su aplicación web en IIS 7.5 o superior, asegúrese de que los servicios de rol para IIS estén habilitados correctamente. Los servicios de rol de interés son: ASP.NET, Autenticación básica, Redirección HTTP, Filtros ISAPI, etc.

Puede ir a los servicios de roles a través de Agregar o Quitar programas - Activar o desactivar las características de Windows. Espero que esto ayude.

Saludos, Kiran Banda

Yo tuve el mismo problema. El mío terminó siendo una asamblea fallida cuando comenzó la aplicación. Permití Fusion Log Viewer para ver qué ensamblajes estaban fallando y lo descubrí. Nunca lo hubiera descubierto, ya que parecía un problema de enrutamiento MVC, pero pensé que publicaría esto en caso de que cualquier otra persona perdiera horas en este problema también.