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

Zainstalowałem DotNetOpenAuth SDK-3.4.5.10201.vsix i nie mogę go uruchomić. Działa lokalnie (kiedy uruchamiam jako localhost), ale kiedy próbuję opublikować, nie działa.

Otrzymuję komunikat o błędzie IIS

Podsumowanie błędów Błąd
HTTP 500.22 - Wewnętrzny błąd serwera
Wykryto ustawienie ASP.NET, które nie ma zastosowania w trybie zintegrowanego potoku zarządzanego.

I

Module       ConfigurationValidationModule  
Notification BeginRequest  
Handler      StaticFile  
Error Code   0x80070032  

istnieją sugestie dotyczące rozwiązania problemu:

Rzeczy, których możesz spróbować:

• Przeprowadź migrację konfiguracji do system.webServer/modulessekcji. Możesz to zrobić ręcznie lub za pomocą AppCmd ​​z wiersza poleceń - na przykład %SystemRoot%\system32\inetsrv\appcmd migrate config "Default Web Site/". Użycie AppCmddo migracji Twojej aplikacji pozwoli na pracę w trybie zintegrowanym i kontynuację pracy w trybie klasycznym oraz na poprzednich wersjach IIS.

• Jeśli masz pewność, że zignorowanie tego błędu jest w porządku, można je wyłączyć, ustawiając wartość system.webServer/validation@validateIntegratedModeConfiguration false.

• Możesz też przełączyć aplikację na pulę aplikacji w trybie klasycznym - na przykład %SystemRoot%\system32\inetsrv\appcmd set app "Default Web Site/" /applicationPool:"Classic .NET AppPool". Zrób to tylko, jeśli nie możesz przeprowadzić migracji aplikacji.
  (Ustaw „Domyślną witrynę sieci Web” i „Klasyczną aplikację .NET AppPool” na ścieżkę aplikacji i nazwę puli aplikacji)

Problem polega jednak na tym, że nie mam dostępu do serwera ISS, ponieważ nie jestem jego właścicielem. Czy jest jakiś sposób na rozwiązanie tego?

W 2 ^nd opcją jest jeden chcesz.

web.configUpewnij się , że te klucze istnieją:

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

Dodanie <validation validateIntegratedModeConfiguration="false"/>adresuje objaw, ale nie jest odpowiednie dla wszystkich okoliczności. Po kilkakrotnym obejrzeniu tego problemu mam nadzieję pomóc innym nie tylko rozwiązać problem, ale także go zrozumieć. (Co staje się coraz ważniejsze, gdy IIS 6 zamienia się w mit i plotki.)

Tło:

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 potokowy, i jest równoważny temu, co IIS 7+ nazywa trybem „klasycznym”. Drugi, nowszy i zalecany tryb potoku dla wszystkich aplikacji działających w IIS 7+ nazywa się trybem „zintegrowanym”.

Jaka jest różnica? Kluczową różnicą jest interakcja programu ASP.NET z usługami IIS.

• Tryb klasycznyjest ograniczony do potoku ASP.NET, który nie może współpracować z potokiem IIS. Zasadniczo przychodzi żądanie i jeśli IIS 6 / Classic zostanie poinformowany, poprzez konfigurację serwera, że ​​ASP.NET może go obsłużyć, to IIS przekazuje żądanie do ASP.NET i przechodzi do następnego etapu. Znaczenie tego można znaleźć na przykładzie. Gdybym miał autoryzować dostęp do plików obrazów statycznych, nie byłbym w stanie tego zrobić z modułem ASP.NET, ponieważ potok IIS 6 sam sobie poradzi z tymi żądaniami, a ASP.NET nigdy nie zobaczy tych żądań, ponieważ nigdy nie zostały przekazane . * Z drugiej strony, autoryzacja, którzy użytkownicy mogą uzyskać dostęp do strony .ASPX, takiej jak żądanie Foo.aspx, jest banalna nawet w IIS 6 / Classic, ponieważ IIS zawsze przekazuje te żądania do potoku ASP.NET. W trybie klasycznym ASP.NET nie wie, co ma

• Tryb zintegrowany jest zalecany, ponieważ procedury obsługi i moduły ASP.NET mogą bezpośrednio współpracować z potokiem IIS. Rurociąg IIS już nie przekazuje żądania do potoku ASP.NET, teraz pozwala on na podłączenie kodu ASP.NET bezpośrednio do potoku IIS i wszystkich żądań, które go trafiły. Oznacza to, że moduł ASP.NET może nie tylko obserwować żądania do statycznych plików obrazów, ale może przechwytywać te żądania i podejmować działania poprzez odmowę dostępu, rejestrowanie żądania itp.

Pokonanie błędu:

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

2. Z drugiej strony być może poprawiasz wygląd swojej aplikacji lub dobrze się z nią łączyłeś, dopóki nie zainstalowałeś biblioteki innej firmy za pomocą NuGet, ręcznie lub w inny sposób. W takim przypadku jest to całkowicie możliwe httpHandlerslub httpModuleszostało dodane do system.web. Wynikiem jest błąd, który widzisz, ponieważ validateIntegratedModeConfigurationdomyślnie true. Teraz masz dwie możliwości:

   1. Usuń elementy httpHandlersi httpModulesz system.web. Istnieje kilka możliwych rezultatów:
      • Wszystko działa dobrze, wspólny wynik;
      • Twoja aplikacja nadal narzeka, w folderze nadrzędnym, z którego dziedziczysz, może znajdować się plik web.config, rozważ też wyczyszczenie tego pliku web.config;
      • Masz już dość usuwania httpHandlersi httpModulesdodawania pakietów NuGet system.web, hej, rób co trzeba.
3. Jeśli te opcje nie działają lub są więcej kłopotów niż to jest warte to ja nie powiem ci, że nie można ustawić validateIntegratedModeConfigurationna false, ale przynajmniej wiesz co robisz i dlaczego jest to ważne.

Dobre czyta:

• ASP.NET 2.0 Łamanie zmian w IIS 7.0
• Integracja ASP.NET z IIS 7
• Przegląd programów HTTP i modułów HTTP

* Oczywiście istnieją sposoby na przeniesienie wszelkiego rodzaju dziwnych rzeczy do potoku ASP.NET z IIS 6 / Classic za pomocą inkantacji, takich jak odwzorowania symboli wieloznacznych , jeśli ci się podobają.

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

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

Natrafiłem na ten problem, ale miałem inną poprawkę. Wymagało to zaktualizowania Control Panel>Administrative Tools>IIS Manageri przywrócenia zarządzanego potoku mojej witryny aplikacji z Integratedna Classic.

Sprawdź, czy nie ma konfliktu w uwierzytelnianiu IIS. tzn. włączysz anonimowe uwierzytelnianie i personifikację ASP.NET, oba mogą również powodować błąd.

Upewnij się, że w pliku web.config istnieją następujące klucze:

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

Jak również sprawdź Asp.Net Impresonation = Disable In IIS Site Authentication

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

1. Interfejs API sieci Web (wersja 4.0.030506.0, znana również jako stara)
2. .NET 4.0
3. Atrybut Routing 3.5.6 dla interfejsu API sieci Web [spoiler alert: to był ten facet!]

Chciałem użyć routingu atrybutów w projekcie, który (niestety) musiał używać .NET 4, a zatem nie mógł używać Web API 2.2 (który potrzebuje .NET 4.5). Dobrze oznaczający pakiet NuGet dodał tę sekcję w <system.web>sekcji:

<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 pomogło mi przejść przez HTTP 500.23 !!

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

To działało dla mnie:

1. Usuń pierwotnie utworzoną witrynę.
2. Odtwórz stronę w IIS
3. Czyste rozwiązanie
4. Zbuduj rozwiązanie

Wygląda na to, że coś poszło na południe, kiedy tworzyłem witrynę. Nienawidzę rozwiązań podobnych do „Uruchom ponownie komputer, a następnie zainstaluj ponownie system Windows”, nie wiedząc, co spowodowało błąd. Ale to zadziałało dla mnie. Szybki i prosty. Mam nadzieję, że pomoże to komuś innemu.

W moim przypadku brakowało dll w folderze bin, do którego odnosił się plik web.config. Sprawdź, czy korzystasz z dowolnego ustawienia w pliku web.config, ale tak naprawdę nie masz biblioteki dll.

Dzięki

Zajęło mi to kilka godzin, aby rozwiązać ten problem, ponieważ wszystkie ustawienia, które znalazłem tutaj o tym błędzie były takie same, ale nadal nie działało. Problem polegał na tym, że miałem folder w mojej usłudze internetowej, z którego plik powinien zostać przesłany do urządzenia WinCE, po przekonwertowaniu tego folderu do aplikacji za pomocą Classic.NetAppPool zaczął działać.

Poniższy krok rozwiązał mój problem:

Otwórz CMDmonit z uprawnieniami administratora.

Biegać : iisreset.

Mam nadzieję że to pomoże.

Metodą lokalną jest błąd