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

Question

Я установил DotNetOpenAuth SDK-3.4.5.10201.vsix и не могу заставить его работать. Он работает локально (когда я запускаю как localhost), но когда я пытаюсь опубликовать его, он не работает.

Я получаю сообщение об ошибке IIS

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

И

Module       ConfigurationValidationModule  
Notification BeginRequest  
Handler      StaticFile  
Error Code   0x80070032  

тогда есть несколько советов о том, как решить проблему:

Что вы можете попробовать:

• Перенос конфигурации в system.webServer/modules раздел. Вы можно сделать это вручную или с помощью AppCmd из командной строки - например, %SystemRoot%\system32\inetsrv\appcmd migrate config "Default Web Site/". Использование AppCmd для миграции вашего приложение позволит ему работать в Интегрированный режим и продолжить работу в классическом режиме и на предыдущем версии IIS.

• Если вы уверены, что можно игнорируйте эту ошибку, ее можно отключить установив system.webServer/validation@validateIntegratedModeConfiguration ложно.

• Либо переключите приложение в пул приложений в классическом режиме - например, %SystemRoot%\system32\inetsrv\appcmd set app "Default Web Site/" /applicationPool:"Classic .NET AppPool". Делайте это только если вы не удалось перенести ваше приложение.
  (Установите «Веб-сайт по умолчанию» и «Классический .NET AppPool» для вашего пути к приложению и имени пула приложений)

Но проблема в том, что у меня нет доступа к серверу МКС, поскольку я не являюсь его владельцем. Есть ли способ решить эту проблему?

Answer 1

Вам нужна опция 2 ^nd .

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

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

Answer 2

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

Справочная информация:

Эта проблема и путаница вокруг нее возникли с появлением ASP.NET 2.0 и IIS 7IIS 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 может не только наблюдать запросы к статическим файлам изображений, но и может перехватывать эти запросы и предпринимать действия, отказывая в доступе, регистрируя запрос и т. Д.

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

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

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

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

Хорошие чтения:

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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

Answer 6

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

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

А также проверьте Asp.Net Impresonation = отключить В аутентификации сайта IIS

Answer 7

Я столкнулся с этой проблемой и воодушевленный ответом @ Джереми Кука, я укусил пулю, чтобы выяснить, что, черт возьми, заставило интегрированный режим IIS 7 не нравиться моему web.config.Вот мой сценарий:

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

Я хотел использовать маршрутизацию атрибутов в проекте, который (к сожалению) должен был использовать .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 !!

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

Answer 8

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

1. Удалить изначально созданный сайт.
2. Восстановить сайт в IIS
3. Чистый раствор
4. Построить решение

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

Answer 9

Мне понадобилось несколько часов, чтобы решить эту проблему, потому что все настройки, которые я нашел здесь об этой ошибке, были такими же, но все равно не работали. Проблема заключалась в том, что в моем веб-сервисе была папка, из которой файл должен быть отправлен на устройство WinCE, после преобразования этой папки в приложение с Classic.NetAppPool оно начало работать.

Answer 10

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

Спасибо