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

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

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

Сводка ошибки
HTTP Error 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 значение false.

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

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

2 - ^й вариант, который вы хотите.

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

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

Добавление <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 не знает, что он имеет

• Рекомендуется интегрированный режим, поскольку обработчики и модули 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 с помощью заклинаний, таких как сопоставления с подстановочными знаками , если вам нравятся такие вещи.

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

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

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

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

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

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

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

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

1. Web API (версия 4.0.030506.0 или старая версия)
2. .NET 4.0
3. Маршрутизация атрибутов 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 !!

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

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

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

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

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

Спасибо

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

Ниже шаг решил мою проблему:

Откройте CMDзапрос с правами администратора.

Запустить : iisreset.

Надеюсь это поможет.

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