AzureでASP.NETMVC4アプリケーションを実行しています。ファイル名のように見えるもの(つまり「favicon.ico」)のカスタムルートがいくつかあります。これらのファイル名のようなルートは、過去2年間、問題なく正常に機能しています。ただし、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」)、FREBログに「NOTIFY_MODULE_START」が表示されていても、IISが拡張機能のあるルートの解決を何らかの形で妨げているようです。 「UrlRoutingModule-4.0」モジュール。
私は何か基本的なものが欠けていますか?次にどこを見ればいいですか?
更新: ServiceConfiguration.Cloud.cscfgを「osFamily」3(Windows Server 2012)にアップグレードすると、IIS8でもこの問題は解決しました。何が起こっていたのかわかりませんが、もう存在しないことを嬉しく思います。FREB-ingは私が望んでいたほど役に立たなかったので、このような状況で役立つかもしれないさらなるデバッグの洞察のコメントまたは追加の回答で聞いてみたいです。