У меня есть проект, который работает со связью, когда вы запускаете его из визуальной студии. Однако после развертывания обработчик связывания никогда не заберет маршрут. Вместо этого он переходит к статическому обработчику файлов, который возвращает ответ 404.
Любые идеи? Я вижу сборку оптимизации в корзине веб-сайта в IIS.
Он использует пул приложений 4.0 и интегрированный режим.
Мне интересно, есть ли у кого-нибудь идеи или предложения?
Спасибо
----- обновление на основе вопросов -----
VS2012
targetFramework = "4.5"
Я также добавил некоторый код в представление, чтобы показать, какие модули были загружены, и я могу видеть список модулей, перечисленных там.
BundleConfig по умолчанию предоставляется при использовании шаблона проекта интернет-приложения MVC4.
Сайт развертывается в корне. Это странно, когда я устанавливаю EnableOptimizations = true (из-за работы в режиме отладки с помощью visual studio F5), он отлично работает! Я могу перейти к контенту /css, и он выплевывает комбинированный css.
Я развертываю его и все остальное работает, но связывание!
Я только что ударил (и решил) эту проблему.
Убедитесь, что виртуальный путь пакета не может быть запутан для существующего каталога или фактического имени файла. В моем случае я закодировал его как:
bundles.Add(new ScriptBundle("~/bundles/main.js").Include( ...
Но когда я изменил его на
bundles.Add(new ScriptBundle("~/bundles/main").Include( ...
все это начало работать.
Обновлен ответ на 17.11.2013 Это связано с тем, что по умолчанию MVC-маршрутизация обрабатывает * вместо *. *, то есть IIS или IIS Express applicationhost.config имеет следующее:
<add name="ExtensionlessUrl-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" responseBufferLimit="0" />
Итак, чтобы обойти это, мы можем добавить следующее в web.config:
<system.webServer>
<handlers>
<add name="UrlRoutingHandler"
type="System.Web.Routing.UrlRoutingHandler,
System.Web, Version=4.0.0.0,
Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a"
path="/bundles/*"
verb="GET"/>
</handlers>
</system.webServer>
Для получения дополнительной информации вы можете обратиться к следующему: http://weblogs.asp.net/owscott/archive/2013/01/16/handing-mvc-paths-with-dots-in-the-path.aspx Поддержка ASP.NET MVC Url Route (точка)
Старый неправильный ответ: В принципе, DOT, как правило, не допускается в виртуальном пути при анализе URL-адресов IIS. Этот ссылка упоминает следующий параметр URLScan AllowDotInPath: По умолчанию эта опция установлена в 0. Если этот параметр установлен в 0, URLScan отклоняет любой запрос, содержащий несколько периодов (.). Это предотвращает попытки маскировки запросов на опасные расширения имен файлов путем размещения безопасного имени имени файла в информации о пути или строке запроса в URL-адресе. Например, если этот параметр установлен в 1, URLScan может разрешить запрос для http://servername/BadFile.exe/SafeFile.htm, потому что он интерпретирует его как запрос для HTML-страницы, когда это фактически запрос на исполняемый файл (.exe) с именем страницы HTML в области PATH_INFO. Если для этой опции установлено значение 0, URLScan также может запрещать запросы для каталогов, содержащих периоды.
Даже я получил ту же ошибку.
Добавление <modules runAllManagedModulesForAllRequests="true" /> в <system.webServer> в файл web.config устраняет проблему.
У меня была такая же проблема даже с образцом приложения MVC. Я видел, что шаблон по умолчанию связывает стиль с именем css, который, я думаю, IIS не любит, что приводит к ошибке 404.
Изменение имени пакета из css в APPCSS решит проблему для меня.