Обнаружен параметр ASP.NET, который не применяется в режиме интегрированного управляемого конвейера

Добавление <validation validateIntegratedModeConfiguration="false"/> устраняет симптом, но не подходит для всех обстоятельств. Несколько раз сталкиваясь с этой проблемой, я надеюсь помочь другим не только преодолеть проблему, но и понять ее. (Что становится все более важным, поскольку IIS 6 исчезает в мифе и слухи.)

Фон:

Эта проблема и путаница вокруг нее начались с внедрения ASP.NET 2.0 и IIS 7. У IIS 6 был и остается только один режим конвейера, и он эквивалентен тому, что IIS 7+ вызывает "классический" режим. Второй, более новый и рекомендуемый режим конвейера для всех приложений, работающих на IIS 7+, называется "Интегрированный" режим.

Итак, какая разница? Основное различие заключается в том, как ASP.NET взаимодействует с IIS.

• Классический режим ограничен конвейером ASP.NET, который не может взаимодействовать с конвейером IIS. По сути, приходит запрос, и если IIS 6/Classic было сказано через конфигурацию сервера, что ASP.NET может справиться с этим, IIS отдает запрос ASP.NET и переходит дальше. Значение этого можно почерпнуть из примера. Если бы я разрешил доступ к файлам статического изображения, я бы не смог сделать это с помощью модуля ASP.NET, потому что конвейер IIS 6 будет обрабатывать эти запросы сам, и ASP.NET никогда не увидит эти запросы, потому что они никогда не были переданы. С другой стороны, авторизация доступа пользователей к странице .ASPX, такой как запрос для Foo.aspx, является тривиальной даже в IIS 6/Classic, поскольку IIS всегда передает эти запросы в конвейер ASP.NET. В классическом режиме ASP.NET не знает, что ему не было сказано, и есть много того, что IIS 6/Classic может не сообщать об этом.

• Рекомендуется использовать встроенный режим, поскольку обработчики и модули ASP.NET могут напрямую взаимодействовать с конвейером IIS. Конвейер IIS больше не передает запрос на конвейер ASP.NET, теперь он позволяет коду ASP.NET напрямую подключаться к конвейеру IIS и всем запросам, которые его ударили. Это означает, что модуль ASP.NET может не только наблюдать запросы к файлам статического изображения, но и перехватывать эти запросы и предпринимать действия, запрещая доступ, регистрируя запрос и т.д.

Преодоление ошибки:

• Если вы запускаете старое приложение, которое изначально было создано для IIS 6, возможно, вы перенесли его на новый сервер, не может быть абсолютно ничего плохого в запуске пула приложений этого приложения в классическом режиме. Идите вперед, вам не нужно плохо себя чувствовать.

• И снова, возможно, вы подаете свое приложение подтяжку лица, или оно прекрасно работает, пока вы не установили стороннюю библиотеку через NuGet, вручную или каким-либо другим способом. В этом случае возможно httpHandlers или httpModules добавлено к system.web. Результатом является ошибка, которую вы видите, потому что validateIntegratedModeConfiguration по умолчанию true. Теперь у вас есть два варианта:

  • Удалите элементы httpHandlers и httpModules из system.web. Есть несколько возможных результатов из этого:
    • Все работает отлично, общий результат;
    • Ваше приложение продолжает жаловаться, может быть файл web.config в родительской папке, из которой вы наследуете, также подумайте об очистке этого web.config;
    • Вы устали от удаления httpHandlers и httpModules, которые пакеты NuGet продолжают добавлять в system.web, ну, сделайте то, что вам нужно.
• Если эти параметры не работают или больше проблем, чем это того стоит, я не буду говорить вам, что вы не можете установить validateIntegratedModeConfiguration в false, но по крайней мере вы знаете, что делаете и почему это имеет значение.

Хорошо читает:

• ASP.NET 2.0 Нарушение изменений в IIS 7.0
• Интеграция ASP.NET с IIS 7
• Обзор HTTP-обработчиков и HTTP-модулей

* Конечно, есть способы получить все странные вещи в конвейере ASP.NET из IIS 6/Classic с помощью заклинаний, таких как подстановочные сопоставления, если вам нравится такая штука.

Если вам все еще нужно использовать HTTP-модуль, вам необходимо его настроить (инфраструктура .NET 4.0) следующим образом:

<system.webServer>
   <modules runAllManagedModulesForAllRequests="true">
       <add name="MyModule" type="[Namespace].[Class], [assembly]"/>
   </modules>
   <validation validateIntegratedModeConfiguration="false"/>
</system.webServer>

Я столкнулся с этой проблемой, но имел другое исправление. Он включал обновление Control Panel>Administrative Tools>IIS Manager и возврат моей управляемой конвейерной площадки приложения с Integrated до Classic.

Проверьте, нет ли конфликта в вашей аутентификации IIS. то есть вы включите анонимную аутентификацию и олицетворение ASP.NET, оба могут вызвать ошибку.

Это сработало для меня:

• Удалить созданный сайт.
• Восстановить сайт в IIS
• Чистое решение
• Построить решение

Кажется, что что-то пошло на юг, когда я изначально создал сайт. Я ненавижу решения, похожие на "Перезагрузите компьютер, а затем переустановите окна", не зная, что вызвало ошибку. Но это сработало для меня. Быстро и просто. Надеюсь, это поможет кому-то другому.

В вашем web.config убедитесь, что эти ключи существуют:

<configuration>
    <system.webServer>
        <validation validateIntegratedModeConfiguration="false"/>
    </system.webServer>
</configuration>

Также проверьте Asp.Net Impresonation = Disable. В Authentication сайта IIS

Я столкнулся с этой проблемой и воодушевлен ответом @Jeremy Cook, я укусил пулю, чтобы узнать, что, черт возьми, привело к тому, что IIS 7 Integrated mode не понравился мой web.config. Здесь мой сценарий:

• Web API (версия 4.0.030506.0, старая)
• .NET 4.0
• Маршрутизация атрибутов 3.5.6 для веб-API [оповещение о спойлере: это был этот парень!]

Я хотел использовать маршрутизацию атрибутов в проекте, который (к сожалению) должен был использовать .NET 4 и, следовательно, не мог использовать Web API 2.2 (для которого требуется .NET 4.5). Нужный пакет NuGet добавил этот раздел в разделе <system.web>:

<system.web>
<httpHandlers>
      <add verb="*" path="routes.axd" type="AttributeRouting.Web.Logging.LogRoutesHandler, AttributeRouting.Web" />
    </httpHandlers>
</system.web>

[Я говорю хорошо, потому что эта часть требуется для более старых версий IIS]

Удаление этого раздела привело меня к HTTP 500.23!

Резюме: Я повторяю, что Джереми говорит, что важно понять, почему все не работает, а не просто "маскирует симптом". Даже если вам нужно замаскировать симптом, вы знаете, что делаете (и почему): -)

В моем случае мне не хватало dll в папке bin, на которую ссылался файл web.config. Поэтому проверьте, используете ли вы какие-либо настройки в web.config, но на самом деле не имеете dll.

Спасибо

Метод для локального является ошибкой