So right now I have two routes:
routes.MapRoute(
"Default", // Route name
"{controller}/{action}/{id}", // URL with parameters
new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults
);
routes.MapRoute(
"Legos",
"{controller}/{action}/{page}",
new { controller = "Legos", action = "Lego", page = UrlParameter.Optional });
If I go to www.website.com, I will be able to see my homepage just fine, but my Legos route doesnt work. Like-wise, if I put my Legos route on top, I can go to www.website.com/Legos/Lego/1 just fine, but going to http://www.website.com thows an error(below), and I need to manually go to www.website.com/Home/Index to see my homepage.
Error:
The parameters dictionary contains a null entry for parameter 'page' of non-nullable type 'System.Int32' for method 'System.Web.Mvc.ActionResult Errors(Int32, System.String)' in 'stuff.Controllers.Legos'. An optional parameter must be a reference type, a nullable type, or be declared as an optional parameter.
Parameter name: parameters
Why would this be?
The reason is that both routes have the same number of parameters and no constraints, so the route handler cannot differentiate between them for an inbound request – it will just go with the first match (i.e. whichever has been added to the route table first).
If you correctly differentiate between your routes then it will work. For example, you could try removing the “id” optional parameter from the “Default” route and making the “page” part of the “Legos” route mandatory (as it appears that it is required for the endpoint to work, this is best practice anyway):
This would mean that a url with two parameters (i.e. Home/Index) would not match the “Legos” route, as it is missing the required “page” parameter – it would then test the “Default” route, which would succeed as “Home/Index” matches the “{anything}/{anything}” format it expects.
Your other option would be to add a route constraint to one of the routes – for example you could make “page” only accept numbers, so if the incoming request looked like {anything}/{anything}/{numeric} it would match the “Legos” route, but if it was non-numeric it wouldn’t match the constraint and would instead hit the default route:
Of course the “problem” with this particular solution would be if you had a numeric id (which lets face it, most are) that you wanted to use for the “default” route, it would end up being caught by the “Legos” route…