Why does Default UrlResolver throw an exception

[waynebrantley]

The current default UrlResolver tries to resolve all routes with 'default' values and throws an exception if it cannot. I do not believe this is necessary and does cause issues - here is an example use case.

If I have defined a route like {controller}/{action}/{myId} and put a constraint on the myId so it has to be an integer larger than 100.

In the sitemap (either XML or code based), you put this:
c# MvcSiteMapNode(Title = "Some Action", ParentKey = "SomeParent")]c#

When the sitemap is loaded, the base class tries to resolve the 'url' property of every node put in the sitemap, which includes this one.

When the default resolver tries to resolve this, it fails - as it should, because there is no 'myId' parameter which is required. The error message says to provide defaults, etc. This means I could add a default to my routevalue of say 100. If I do this it can resolve it. However, that means if the value is not passed it the action will be called with a value of 100 - sort of defeats the purpose of the constraints!

What I propose is a simple change at the end of the code for UrlResolver. Here is the current code:

if (string.IsNullOrEmpty(returnValue))
{
    throw new UrlResolverException(string.Format(Messages.CouldNotResolve, mvcSiteMapNode.Title, action, controller, mvcSiteMapNode.Route ?? ""));
}

 _urlkey = key;
_url = returnValue;
return returnValue;

We simply do not throw that exception! This is only resolving because it was added to the sitemap and we are of course only going to call it with valid parameters in our code...so this change seems to work fine - and I cannot find any negative impacts.

if (string.IsNullOrEmpty(returnValue))
{
    return Guid.NewGuid().ToString();
}

 _urlkey = key;
_url = returnValue;
return returnValue;

Any thoughts on this? Why did it used to throw an exception anyway? Anything you can think of this will break? Seems to work fine for me.

[visoft]

@waynebrantley - Thank you so much for this fix! I've been using Restful Routing in my MVC app. I was having issues with my resource based routes (e.g. edit) because it requires an id in the Url. It's not an optional parameter, so thus the default resolver was throwing exceptions. This workaround seems to work perfectly.

[pradeepn]

The above fix worked for me. Thanx for the fix. But if the site is in virtual directory it
throws error that the url is outside the app path for the website like localhost/site1

if (string.IsNullOrEmpty(returnValue))
{
    return "~/"+ Guid.NewGuid().ToString();
}
 _urlkey = key;
_url = returnValue;
return returnValue;

[NightOwl888]

Thanks for finding this. There are methods within the .NET framework to build the url using a virtual app path rather than the "~/" syntax that could be used for this purpose. I ran across a few of these methods in an internal static library called UrlPath when extracting the code for v4.

I will make sure this works in a virtual directory before the release.

[NightOwl888]

FYI - I changed this slightly for the v4 fix:

return VirtualPathUtility.ToAbsolute("~/") + Guid.NewGuid().ToString();

[NightOwl888]

@maartenba, @waynebrantley, @pradeepn, @visoft

What if we did this instead for this case?

return "#";

This would have been a problem back when this was first included because the route URLs were being added to a dictionary and no duplicates URLs were allowed. However, now that is not being done anymore.

To me it seems like returning a link that does nothing (aside from scrolling to the top) when you click on it would be better than returning one that generates a 404 not found. Neither one gives you a clear indication what is wrong, but at least the former doesn't also cause usability issues.

Thoughts?

[maartenba]

I'd vote yes. SOunds like a good compromise.

[visoft]

Sounds good to me as well.