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

Question

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 para parecer servir el contenido correctamente. 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 he tenido problemas para implementar esta misma aplicación en servidores IIS 7.5 en Windows 7 y Windows Server 2008 R2.

Antes del despliegue, el servidor 2008 no tiene .NET 4.0 o instalado ASP.NET MVC 3, así que aquí están los pasos que comprometido antes de la implementación de 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 usando el instalador plataforma web
4. Aplicada MS actualizar KB980368 para permitir cierta IIS 7.0 o IIS 7.5 manipuladores para manejar peticiones cuyos URL no termines con una p eriod

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 MS knowledge base article que menciona que debe asegurarse de que la redirección HTTP y la compresión de contenido estático estén habilitadas/instaladas en el servidor donde experimenta 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 de por qué esto no funciona correctamente. Pude replicar el problema en 2 servidores diferentes de IIS 7.0. ¿Qué me estoy perdiendo?

Answer 1

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.

Answer 2

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.

Apenas añada lo siguiente a su web.config:

<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 deben ejecutarse en cada solicitud web, incluso si IIS determina que se trata de un archivo estático o una carpeta.

Answer 3

Asegúrese de que se está ejecutando en 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

Answer 4

Si está ejecutando la aplicación Web en IIS 7.5 o superior, por favor asegúrese de que los servicios de función para IIS están activados 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 rol a través de Agregar o quitar programas - Activar o desactivar las características de Windows. Espero que esto ayude.

Saludos, Kiran Banda

Answer 5

Mi solución, después de intentar todo:

Malo despliegue, un viejo PreCompiledApp.config estaba colgando alrededor de mi ubicación de despliegue, y haciendo todo lo que no funciona.

Mis ajustes finales que ha trabajado:

• IIS 7.5, 64, Win2k8r2
• grupo de aplicaciones de modo integrado

• nada cambia en el web.config - esto significa que no hay controladores especiales para enrutamiento . Aquí está mi instantánea de las secciones de muchas otras publicaciones de referencia. Estoy usando FluorineFX, por lo que tiene que manejador añadió, pero no necesitará 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: (único método 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 logra una conversión automática http://andrew.arace.info/stackoverflow-http://andrew.arace.info/#stackoverflow que luego sería manejada por el 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; 
      } 
  } 
  

Answer 6

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.