2008-11-25 19 views
14

Parece que no puedo resolver esto. Estoy experimentando con MVC Beta y estoy tratando de implementar una ruta atrasada de manera que si el usuario ingresa a mysite.com/blah en lugar de a mysite.com/home/index, se golpeará la ruta "Error"..Net MVC Routing Catchall no funciona

Desafortunadamente parece que la ruta "Predeterminada" siempre capta "bla" primero. De hecho, la única ruta que he podido llegar a la ruta de "Error" es bla/bla/bla/bla.

Así es como debería funcionar, porque he visto otros ejemplos que tienen la ruta "Predeterminada" y "Error" configurada así y parece que si tuvieran que escribir un controlador que no funciona 't existir, golpearía la ruta de "Error".

¿Hay algo que me falta (muy posible) o tendré que crear una ruta específica para cada controlador?

Código

que estoy usando:

 routes.MapRoute(
      "Default",            // Route name 
      "{controller}/{action}/{id}",       // URL with parameters 
      new { controller = "Home", action = "Index", id = "" } // Parameter defaults 
     ); 

     routes.MapRoute(
      "Error", 
      "{*catchall}", 
      new { controller = "Base", action = "Error", id = "404" } 
     ); 

Gracias, Jeff

rutas

Respuesta

2

MVC se comprueban en el orden en que se introducen.

Mysite/blah se encontrará por la ruta predeterminada. El controlador será blah, y la acción es índice.

Cuando ingresó a la ruta mysite/blah/blah/blah/blah, le asignó una ruta a la que no se pudo asignar la ruta predeterminada y luego se llamó a su ruta atrapada.

Para esos otros ejemplos, ¿notó si tenían algunos filtros de error configurados? Estoy bastante seguro de que el sitio asp.net mvc predeterminado ya tiene algunos atributos de manejo de errores en las páginas.

+0

Gracias, ese es el entendimiento al que llegué, pero que simplemente no quería aceptar en base a lo que he visto y lo que espero. Pero aprenderé a lidiar con eso. –

5

Con el fin de controlar los errores que utiliza el evento Application_Error en uno de mis proyectos:

protected void Application_Error(object sender, EventArgs e) 
{ 
    Exception exception = Server.GetLastError(); 
    HttpException httpException = exception as HttpException; 
    if (httpException != null) 
    { 
     RouteData routeData = new RouteData(); 
     routeData.Values.Add("controller", "Error"); 
     routeData.Values.Add("action", "HttpError500"); 

      if (httpException.GetHttpCode() == 404) 
      { 
       routeData.Values["action"] = "HttpError404"; 
      } 

     Server.ClearError(); 
     Response.Clear(); 
     IController errorController = new ErrorController(); 
     errorController.Execute(new RequestContext(new HttpContextWrapper(Context), routeData)); 
    } 
} 
+0

Este es el lugar incorrecto para realizar el manejo de excepciones, y también está cambiando el significado de una excepción al eliminarla.Esto podría hacer que la depuración sea muy, muy difícil. –

+1

No veo por qué usar el controlador Application_Error dificultaría la depuración. Si registra la excepción, tendrá el seguimiento completo de la pila. Otro problema con la ruta * catchall es que no se llamará si se produce una excepción en una acción de controlador, por lo que si desea manejar 500 errores deberá hacerlo en otro lugar. Prefiero tener todo el código de manejo de excepciones en un solo lugar. –

+0

El mayor problema es que pierdes gran parte de tu contexto cuando el error llega a Application_Error, como el objeto de sesión, y si no cuentas por esas cosas, la depuración se convierte en una pesadilla. –

6

Su primera ruta se captura la mayor cantidad de direcciones URL ya que tienen valores por defecto para los elementos, se puede visualizar esto utilizando la ruta depurador de Phil Haack, ver el enlace:

Route Debugger

+0

Esto parece útil también. ¡Gracias! –

0

Esto también puede ayudar cuando se trata de problemas catchall MVC:

routes.MapRoute(
    "Default",            // Route name 
    "{controller}/{action}/{*id}",       // URL with parameters 
    new { controller = "Home", action = "Index", id = "" } // Parameter defaults 
); 

Es decir, donde dice {id}, cámbielo a {*id}. Esto permite que el parámetro id final para consumir trayectoria tanto adicional que sea aprobada en la regla por defecto acepta esto:.

/persona/nombre/Joe

Pero no esto:

/productos/lista/sortby/name

La segunda URL arrojará un 404 sin esta modificación a la ruta.

+0

He intentado esto y he estado en internet tratando de resolverlo, pero no funciona para mí. Si paso 2 segmentos en la URL obtengo el error 404 ya sea que agregue el asterisco o no. ¿Algún consejo? – DavidHyogo

+0

Esto puede ser mejor como una nueva pregunta: ¿cuáles son los valores predeterminados que está configurando (tercera línea en este ejemplo)? Una muestra de código completo sería lo mejor, lo que requiere una pregunta por separado. –

+0

Buena idea Chris, pero encontré mi tonto error. Estaba definiendo mis rutas en el lugar incorrecto para MVC 4, y estaban siendo ignoradas. Ver mi respuesta en http://stackoverflow.com/questions/7515644/infinite-url-parameters-for-asp-net-mvc-route/14835667#14835667 ¡Ahora estoy felizmente creando todo tipo de definiciones de ruta de lujo! – DavidHyogo

Cuestiones relacionadas