И 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
тогда есть несколько предложений о том, как решить эту проблему:
вещей, которые вы можете попробовать:
перенесите конфигурацию на . Вы можете сделать это вручную или с помощью командной строки из командной строки, например,
%SystemRoot%system32inetsrvappcmd migrate config "Default Web Site/"
. ИспользуяAppCmd
для переноса приложение позволит ему работать в Интегрированный режим, и продолжить работу в классическом режиме и на предыдущем версия IIS.если вы уверены, что это нормально игнорировать эту ошибку, она может быть отключена установив
system.webServer/validation@validateIntegratedModeConfiguration
значение false.кроме того, переключение приложения в пул приложений классического режима - например,
%SystemRoot%system32inetsrvappcmd set app "Default Web Site/" /applicationPool:"Classic .NET AppPool"
. Только сделай это, если ты ... невозможно перенести приложение.
(Установите "веб-сайт по умолчанию" и "Classic .NET AppPool" для вашего пути приложения и имени пула приложений)
но проблема в том, что у меня нет доступа к серверу ISS, поскольку я не являюсь его владельцем. Есть ли способ решить эту проблему?
10 ответов
в 2nd опция-это то, что вы хотите.
в своем 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.аспн тривиально даже в 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, вручную или каким-то другим способом. В таком случае это вполне возможно!--1--> или
httpModules
добавленоsystem.web
. Результатом является ошибка, которую вы видите, потому чтоvalidateIntegratedModeConfiguration
по умолчаниюtrue
. Теперь у вас есть два варианта:- удалить
httpHandlers
иhttpModules
элементыsystem.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 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
и возврат управляемого конвейера моего сайта приложения из Integrated
to Classic
.
проверьте, есть ли какой-либо конфликт в вашей аутентификации IIS. т. е. вы включаете анонимную аутентификацию и ASP.NET олицетворение обоих может также вызвать ошибку.
в интернете.config убедитесь, что эти ключи существуют:
<configuration>
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
</system.webServer>
</configuration>
а также проверьте Asp.Net Impresonation = Отключить в аутентификации сайта IIS
Это сработало для меня:
- удалить первоначально созданный сайт.
- воссоздать сайт в IIS
- очистить решение
- построить решение
кажется, что-то пошло на юг, когда я изначально создал сайт. Я ненавижу решения, которые похожи на" перезагрузить машину, а затем переустановить windows", не зная, что вызвало ошибку. Но это сработало для меня. Быстро и просто. Надеюсь, это поможет кому-то еще.
я столкнулся с этой проблемой и, вдохновленный ответом @Jeremy Cook, я укусил пулю, чтобы узнать, что, черт возьми, вызвало интегрированный режим IIS 7 не нравится мой веб.конфиг. Вот мой сценарий:
- Web API (версия 4.0.030506.0 aka старая)
- .NET 4.0 :
<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, но на самом деле не имеют dll.
спасибо