Question

我在Azure上运行了一个ASP.NET MVC 4应用程序。我有一些看似文件名的自定义路由（即“favicon.ico”）。这些类似文件名的路由在过去两年中运行良好，没有任何问题。但是，当我从Azure SDK 1.7升级到1.8时，这些类似文件名的路由停止工作。

它在IIS Express的本地调试环境中工作正常，因此它似乎不是web.config文件或RouteCollection问题。

我们将“runAllManagedModulesForAllRequests”设置为“true”和“RouteTable.Routes.RouteExistingFiles = true”。此外，磁盘上不存在这些类似文件的路由。

我检查了升级前和升级后计算机上的失败请求跟踪日志。它们看起来很相似，只是工作的升级前部署有一个从“StaticFile”到“System.Web.Mvc.MvcHandler”的FREB“HANDLER_CHANGED”事件，而坏的升级后部署从未这样做（它保留在“StaticFile”中） “处理程序”并最终发送404。

因此，如果UrlRoutingModule具有扩展名并且因此没有给出MvcHandler，则它似乎不再正确地解析该路由。但是，所有非扩展路由工作正常（即“some / test”）所以看起来IIS现在以某种方式阻止了具有扩展的路由的解析，即使在FREB日志中我看到“NOTIFY_MODULE_START” “UrlRoutingModule-4.0”模块。

我错过了一些基本的东西吗？我应该在哪里看下一个？

更新：将我们的ServiceConfiguration.Cloud.cscfg升级到“osFamily”3（Windows Server 2012），因此IIS 8也使这个问题消失了。我不确定发生了什么，但很高兴它不再存在。我很乐意在评论或其他答案中听到进一步的调试见解，这些见解在这些情况下可能会有所帮助，因为FREB-ing并不像我希望的那样有用。

Answer 1

刚刚查看了我们的配置和服务器。我们使用SDK 1.8的更新切换到Server 2012。我们使用Server2012-＆gt; osFamily =“3”osVersion =“*”schemaVersion =“2012-10.1.8”并提供动态XML（即sitemap.xml），没有问题：

“runAllManagedModulesForAllRequests”设置为“true”
我们不指定RouteTable.Routes.RouteExistingFiles

路由配置如下：

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

并且Action方法用以下内容修饰：

[ActionName("sitemap.xml")]

带有文件扩展名的ASP.NET MVC路由不再适用于生产

1 个答案: