Na ASP.NET wykryto ustawienie, które nie ma zastosowania w trybie zintegrowanego zarządzanego potoku

Dodanie <validation validateIntegratedModeConfiguration="false"/> rozwiązuje objaw, ale nie jest odpowiednie dla wszystkich okoliczności. Po obejrzeniu tej kwestii kilka razy, mam nadzieję pomóc innym nie tylko przezwyciężyć problem, ale go zrozumieć. (Co staje się coraz ważniejsze, gdy IIS 6 znika w mity i plotki.)

Background:

Ten problem i zamieszanie wokół niego zaczęło się od wprowadzenia ASP.NET 2.0 i IIS 7. IIS 6 miał i nadal ma tylko jeden tryb potoku i jest równoważny co IIS 7 + nazywa tryb "klasyczny". Drugi, nowszy i zalecany tryb rurociągu dla wszystkich aplikacji działających w IIS 7+ nazywa się trybem "zintegrowanym".

Więc, co za różnica? Zasadnicza różnica polega na tym, jak ASP.NET współdziała z IIS.

• Tryb klasyczny jest ograniczony do ASP.NET rurociąg, który nie może wchodzić w interakcje z rurociągiem usług IIS. Zasadniczo pojawia się żądanie i jeśli IIS 6 / Classic został poinformowany, poprzez konfigurację serwera, że ASP.NET poradzi sobie z tym. następnie IIS przekazuje prośbę do ASP.NET i idzie dalej. Znaczenie tego można wyciągnąć na przykładzie. Gdybym miał autoryzować dostęp do statycznych plików graficznych, nie byłbym w stanie tego zrobić z ASP.NET moduł, ponieważ rurociąg IIS 6 sam obsłuży te żądania i ASP.NET nigdy nie zobaczy tych próśb, ponieważ nigdy nie zostały przekazane.* Z drugiej strony, autoryzowanie, które użytkownicy mogą uzyskać dostęp do .Strona ASPX taka jak prośba o Foo.aspx jest banalny nawet w IIS 6 / Classic bo IIS zawsze przekazuje te prośby do ASP.NET rurociąg. W trybie klasycznym ASP.NET nie wie, czego nie zostało powiedziane i jest wiele, że IIS 6 / Classic może tego nie mówić.

• Tryb zintegrowany jest zalecany, ponieważ ASP.NET moduły obsługi i moduły mogą współdziałać bezpośrednio z rurociągiem IIS. Już rurociąg IIS po prostu nie przekazuje żądania do ASP.NET rurociągu, teraz pozwala ASP.NET kod do podłączenia bezpośrednio do rurociągu IIS i wszystkich / align = "left" / Oznacza to, że ASP.NET moduł może nie tylko obserwować żądania do statycznych plików graficznych, ale może przechwytywać te żądania i podejmować działania, odmawiając dostępu, rejestrując żądanie itp.

Przezwyciężenie błędu:

1. Jeśli używasz starszej aplikacji, która została pierwotnie zbudowana dla IIS 6, być może przeniosłeś ją na nowy serwer, nie może być absolutnie nic złego w uruchamianiu puli aplikacji tej aplikacji w trybie klasycznym. Idź. nie musisz czuć się źle.

2. Potem znowu może dajesz aplikacji face-lift lub było chugging wzdłuż tylko dobrze, dopóki nie zainstalowano biblioteki 3rd party przez NuGet, ręcznie, lub w inny sposób. W takim przypadku jest całkowicie możliwe, że httpHandlers lub httpModules zostały dodane do system.web. Wynikiem jest błąd, który widzisz, ponieważ validateIntegratedModeConfiguration defaults true. Teraz masz dwa wyjścia:

   1. Usuń httpHandlers i httpModules elementy z system.web. Istnieją kilka możliwych rezultatów z tego:
      • Wszystko działa dobrze, wspólny wynik;
      • Twoja aplikacja nadal skarży się, może być sieć.config w folderze nadrzędnym, z którego dziedziczysz, rozważ oczyszczenie tej sieci.config too;
      • masz dość usuwania httpHandlers i httpModules, które pakiety NuGet dodają do system.web, Hej, rób co musisz.
3. Jeśli te opcje nie działają lub są bardziej kłopotliwe niż jest to warte, to jestem nie powiem ci, że nie możesz ustawić validateIntegratedModeConfiguration na false, ale przynajmniej wiesz, co robisz i dlaczego to ma znaczenie.

Dobry czyta:

• ASP.NET 2.0 przełomowe zmiany w IIS 7.0
• ASP.NET integracja z IIS 7
• Obsługa HTTP i moduły http przegląd

*oczywiście są sposoby, aby dostać wszelkiego rodzaju dziwne rzeczy do ASP.NET rurociągu z IIS 6 / Classic poprzez inkantacje jak mapowanie wieloznaczne , jeśli lubisz takie rzeczy.

Jeśli nadal musisz używać modułu HTTP, musisz go skonfigurować (. NET 4.0 framework) w następujący sposób:

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

Napotkałem ten problem, ale miałem inną poprawkę. Wymagało to aktualizacji Control Panel>Administrative Tools>IIS Manager i przywrócenia zarządzanego potoku z Integrated do Classic.

Sprawdź, czy w Twoim uwierzytelnianiu usług IIS nie występuje konflikt. tj. użytkownik włącza uwierzytelnianie anonimowe i ASP.NET podszywanie się pod obu może również spowodować błąd.

W sieci.config upewnij się, że te klucze istnieją:

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

Jak również sprawdzić Asp.Net Impresonacja = Disable in iis site Authetication

To mi się udało:

1. Usuń pierwotnie utworzoną stronę.
2. odtworzenie strony w IIS
3. czysty roztwór
4. Zbuduj rozwiązanie

Wygląda na to, że coś poszło nie tak, kiedy stworzyłem tę stronę. Nienawidzę rozwiązań, które są podobne do "Uruchom ponownie komputer, a następnie ponownie zainstaluj system windows", nie wiedząc, co spowodowało błąd. Ale to mi pomogło. Szybko i prosto. Mam nadzieję, że to pomoże komuś innemu.

Napotkałem ten problem i zainspirowany odpowiedzią @ Jeremy Cook, ugryzłem kulę, aby dowiedzieć się, co do cholery spowodowało, że zintegrowany tryb IIS 7 nie lubi mojej sieci.config. Oto mój scenariusz:

1. Web API (Wersja 4.0.030506.0 aka the old one)
2. . NET 4.0
3. attribute Routing 3.5.6 dla Web API [Spoiler alert: to był ten facet!]

Chciałem użyć trasowania atrybutów w projekcie, który (niestety) musiał używać. NET 4 i dlatego nie mógł używać Web API 2.2 (który potrzebuje. NET 4.5). Pakiet NuGet dodał tę sekcję w sekcji <system.web>:

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

[mówię dobrze, ponieważ ta część jest wymagana w starszych wersjach IIS]

Usunięcie tej sekcji sprawiło, że przeszedłem HTTP 500.23!!

Podsumowanie: Popieram słowa Jeremy ' ego, że ważne jest, aby zrozumieć, dlaczego rzeczy nie działają, a nie tylko "maskowanie objawu". Nawet jeśli musisz zamaskować objaw, wiesz, co robisz (i dlaczego): -)

W moim przypadku brakowało mi dll w folderze bin, który został odwołany w web.plik konfiguracyjny. Sprawdź więc, czy używasz żadnych ustawień w sieci.config ale faktycznie nie mają dll.

Thanks

Metoda local to błąd