Почему мой IIS 7 отказывается обслуживать css или js, когда я изменяю «Включить 32-битные приложения» на False

Question

У меня очень простое веб-приложение (asp.net MVC3, .net 4, использующее IIS, а не встроенный сервер Visual Studio, 64-битная Windows 7). Когда я изменяю настройки в пуле приложений для своего приложения и устанавливаю «Включить 32-разрядные приложения» в значение «Ложь», отображается представление моего приложения, но не отображается статическое содержимое (Content / Site.css или Scripts / myScript.js) вверх. Вместо этого я получаю код состояния 500 по этим запросам.

Ошибка HTTP 500.0 - Внутренняя ошибка сервера Невозможно отобразить страницу, поскольку произошла внутренняя ошибка сервера.

Причина, по которой я изменяю это значение, заключается в том, что я пытаюсь использовать 64-разрядный Oracle.DataAccess.dll, и если для меня установлено значение True, это заставляет пул приложений работать в режиме WOW64, и он пытается загрузить dll с неверным форматом.

Я искал в Интернете некоторое время и не могу найти много информации об этом. Я пытался играть с правами доступа к файлам, я пытался запустить aspnet_regiis со всеми видами флагов. У меня нет идей. Почему IIS не обслуживает этот статический контент при работе в 64-битном режиме?

Answer 1

Когда у меня возникла эта ошибка, в system.webServer \ staticContent в web.config возникла проблема.

Из-за разницы между серверами на одном компьютере требовался определенный тип MIME, но этоошибка на другом.

Отказоустойчивым было бы включить для каждого, что у вас есть в web.config, чтобы избежать получения 500, если не требуется.

Answer 2

Весьма вероятно, что в вашей настройке IIS вы случайно установили 32-битный модуль, что препятствует работе всего веб-приложения в 64-битном модуле.Это частая причина таких 500 ошибок.

Трассировка сбойного запроса должна показать вам больше информации о том, какой это модуль,

http://www.iis.net/learn/troubleshoot/using-failed-request-tracing/troubleshooting-failed-requests-using-tracing-in-iis

Answer 3

Двойная проверка типов MIME правильно назначена, возможно, это связано с двойной записью MIME-типов для локального сайта web.config и самого сервера.

Answer 4

Необходимость оставлять комментарии здесь, так как у меня недостаточно очков, чтобы комментировать.

Вы пытались проверить сопоставление обработчика на своем веб-сайте.

В разделе Сопоставления обработчика: убедитесь, что обработчик StaticFileеще зарегистрирован и что путь назначен на *

Также убедитесь, что он включен.

Answer 5

Только что сам решил эту проблему с включенной защитой Windows и ананамным доступом.

Решение в моем случае состояло в том, чтобы добавить сайт localhost в мои локальные сайты в интрасети. Запуск Visual Studio в режиме администратора также может решить проблему.