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


401

Я установил 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» для вашего пути к приложению и имени пула приложений)

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

Ответы:


782

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

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

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

10
Это не должно влиять на безопасность вашего приложения. Он просто отключает предупреждение о том, что у вас есть некоторые значения конфигурации, которые не будут использоваться.
Дэвид

19
Это не слишком разумный совет, если у вас есть настройки, которые не будут использоваться, вы должны удалить их.
Seph

33
@ Сейф, не согласен с тем, что это неправильный совет. Многие установки NuGet (например, DotLess) будут добавлять записи в разделы, относящиеся к интегрированному режиму, а также дублировать этот параметр для неинтегрированного режима. Это называется переносимостью и позволяет вашей конфигурации работать независимо от того, используете ли вы IIS7 / встроенный или классический. Единственная причина оставить этот параметр проверки в trueтом, что вы можете оставить свои тренировочные колеса и заставить IIS кричать на вас всякий раз, когда вы добавляете параметр, который не будет работать в интегрированном режиме. Это для неопытных, но мешает.
Кирк Волл

5
Такая конфигурация раздражает. @MS: есть лучший способ.
yonexbat

3
Для тех, кто предпочитает исправлять ошибки, а не маскировать симптомы, я разместил альтернативный ответ. Что касается пакетов NuGet, почему мы все еще ориентируемся на IIS 6 / Classic?
Джереми Кук

104

Добавление <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 из IIS 6 / Classic с помощью заклинаний, таких как сопоставления с подстановочными знаками , если вам нравятся такие вещи.


+1 Единственное решение - это не ответ вашей проблемы, а решение с объяснением, которое является идеальным ответом. Что это такое и почему мы должны это изменить, эти ответы на вопросы даны @Jeremy cook answer.
Рикин Патель

Это объяснение привело меня к решению проблемы небольшого тестового сайта, размещенного в IIS 7.5 в интегрированном режиме. Когда я создал новый проект MVC, он добавил httpModule, Microsoft.ApplicationInsights.Web.ApplicationInsightsHttpModule в мой Web.config. Это связано с тем, что при создании нового проекта веб-приложения ASP.NET я оставил флажок «Добавить представление приложения в проект». Когда я удалил httpModule из Web.config, сайт работал без ошибок. Установка для validateIntegratedModeConfiguration значения false сработало, но это был просто полосовой подход.
iCode

2
Обнаружен параметр ASP.NET, который не применяется в режиме интегрированного управляемого конвейера. Это еще одно бесполезное сообщение об ошибке Microsoft. ASP.net имеет тысячи настроек, но Microsoft не думала включать тот, который вызывает ошибку, в текст ошибки. MS управляется маркетологами, а не инженерами, поэтому не ожидайте улучшения в ближайшее время. :-(
Пол Маккарти

35

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

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

2
Я думаю, что свойство HttpModules в system.web для ASP 3.5 или ранее. Для ASP 4 или выше используйте модули в system.webserver
Trio Cheung

1
@HoyCheung на самом деле вопрос использования интегрированного или классического конвейера, а не какой версии .Net, которая решает, использовать ли system.web / httpModules или system.webServer / modules.
Паули Остеро

29

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


3
Договорились - это лучший вариант, а не просто сокрытие ошибки! Убедитесь, что вы используете правильный пул приложений - должен быть классический, а не интегрированный
Swomble

1
Я использую Visual Studio 2012, как я могу изменить пул приложений на классический.

10
Это не очень хорошее решение, если вы хотите использовать все новые функции, доступные в Integrated Pipeline. Это все равно что говорить о возвращении к .NET 2.0 из 4.0 из-за проблемы.
Тревор де Коеккок

Для этого в диспетчере IIS перейдите Application Poolsв дерево слева, дважды щелкните пул, который вы хотите изменить, и выберите режим конвейера.
Стив Смит

8

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


5

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

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

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


3

Я столкнулся с этой проблемой и, вдохновленный ответом @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 !!

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


Спасибо. Я добавил AttributeRouting, включая пакет NuGet для надстройки Api Controller, и удалив раздел, указанный вами в web.config, решил проблему. Тем не менее, я немного обеспокоен, потому что мое веб-приложение MVC уже использовало .NET Framework 4.5.
Роберт Ошлер

2
@ RobertOschler, если вы работаете в .NET 4.5, у вас уже есть встроенная маршрутизация атрибутов в AFAIK - вам не нужен этот NuGet?
Судханшу Мишра

Спасибо и дерьмо. Сегодня прошло несколько часов, пока пакет AttributeRouting работал с NuGet. Я вытащил его и отменил все исправления кода, которые добавил, чтобы он заработал, и заменил атрибут Web API 2 Route () на атрибут GET (). Работал отлично. Сегодня нам действительно нужна экспертная система, чтобы помочь нам со всеми этими пакетами.
Роберт Ошлер

2

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

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

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


0

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

Спасибо


0

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


0

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

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

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

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


-1

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

образ


7
Не меняйте этот параметр, если вы действительно не знаете, что делаете. Это почти никогда не правильный ответ.
NickG
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.