current community

your communities

more stack exchange communities

Stack Exchange
tour help
stack overflow careers
Take the 2-minute tour ×
Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.
up vote 2 down vote favorite
1

I have an ASP.NET MVC 4 application running on Azure. I have some custom routes for things that look like filenames (i.e. "favicon.ico"). These filename-like routes have worked fine for the past 2 years without problems. However, when I upgraded from Azure SDK 1.7 to 1.8, these filename-like routes stopped working.

It works fine in the local debugging environment with IIS express, so it doesn't appear to be a web.config file or a RouteCollection issue.

We have "runAllManagedModulesForAllRequests" set to "true" and "RouteTable.Routes.RouteExistingFiles = true". Furthermore, these file-like routes do not exist on disk.

I checked the Failed Request Trace Logs on both a pre-upgrade and post-upgrade machine. They appear to be similar except that the working pre-upgrade deployment has a FREB "HANDLER_CHANGED" event from "StaticFile" to "System.Web.Mvc.MvcHandler" whereas the bad post-upgrade deployment never does (it stays with the "StaticFile" handler) and eventually sends a 404.

Thus, it appears that the UrlRoutingModule is no longer properly resolving the route if it has an extension and thus not giving the MvcHandler. However, all non-extension routes are working fine (i.e. "some/test") so it appears that IIS is somehow now preventing the resolution of a route with an extension even though in the FREB log I'm seeing "NOTIFY_MODULE_START" on the "UrlRoutingModule-4.0" module.

Am I missing something basic? Where should I look next?

UPDATE: Upgrading our ServiceConfiguration.Cloud.cscfg to "osFamily" 3 (Windows Server 2012) and thus IIS 8 as well made this problem go away. I'm not sure what was happening, but am glad it's no longer present. I'd love to hear in the comments or additional answers of further debugging insights that might be helpful in situations like these since FREB-ing wasn't as helpful as I'd hoped.

share|improve this question
1  
what OS version are you using in the Cloud Service? –  viperguynaz Mar 11 '13 at 20:31
    
W2K8R2 -> osFamily="2" osVersion="*" schemaVersion="2012-10.1.8" –  Jeff Moser Mar 11 '13 at 20:32

1 Answer 1

up vote 2 down vote accepted

Just reviewed our configs and servers. We switched to Server 2012 with the update to SDK 1.8. We use Server2012-> osFamily="3" osVersion="*" schemaVersion="2012-10.1.8" and serve dynamic XML (i.e. sitemap.xml) with no problem:

  • "runAllManagedModulesForAllRequests" set to "true"
  • we don't specify RouteTable.Routes.RouteExistingFiles

Routes are configured like:

routes.MapRoute(
    "sitemap.xml",
    "sitemap.xml",
    new { controller = "Sitemap", action = "sitemap.xml" }
);

and the Action method is decorated with:

[ActionName("sitemap.xml")]
share|improve this answer
    
I've tried setting RouteExistingFiles to both true and false without any change in behavior. I'll try bumping the osFamily to 3 to get 2012. –  Jeff Moser Mar 11 '13 at 20:54
    
It seems like the bump to "osFamily" 3 (Windows Server 2012/IIS 8) made this problem disappear! It doesn't really explain what was happening, but I'll take it. –  Jeff Moser Mar 11 '13 at 21:33
    
I've noticed that in new projects, the web.config template adds 3 system.webServer handlers: ExtensionlessUrlHandler-ISAPI-4.0_32bit / 64-bit / and ExtensionlessUrlHandler-Integrated-4.0. These aren't in our old projects but they are included in IIS8 on Server 2012. –  viperguynaz Mar 11 '13 at 22:33

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.