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

401

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?

Mikael
źródło

Odpowiedzi:

782

W 2 nd opcją jest jeden chcesz.

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

<configuration>
    <system.webServer>
        <validation validateIntegratedModeConfiguration="false"/>
    </system.webServer>
</configuration>
David
źródło
10
To nie powinno tak naprawdę wpływać na bezpieczeństwo Twojej aplikacji. To po prostu wyłącza ostrzeżenie, że masz pewne wartości konfiguracyjne, które nie będą używane.
David
19
To nie jest zbyt rozsądna rada, jeśli masz ustawienia, które nie będą używane, powinieneś je usunąć.
Wrz
33
@Seph, nie zgadzam się, że to nie jest dobra rada. Wiele instalacji NuGet (na przykład DotLess) doda wpisy do sekcji dotyczących trybu zintegrowanego, a także powieli to ustawienie dla trybu niezintegrowanego. Nazywa się to przenośnością i pozwala na konfigurację bez względu na to, czy używasz IIS7 / zintegrowany czy klasyczny. Jedynym powodem, dla którego należy pozostawić to ustawienie sprawdzania poprawności, truejest pozostawienie włączonych kół treningowych i krzyczenie na Ciebie usług IIS za każdym razem, gdy dodasz ustawienie, które nie będzie działać w trybie zintegrowanym. To jest dla niedoświadczonych, ale przeszkadza.
Kirk Woll,
5
Ten rodzaj konfiguracji jest denerwujący. @MS: istnieje lepszy sposób.
yonexbat
3
Dla tych, którzy wolą naprawiać błędy niż maskować objawy, zamieściłem alternatywną odpowiedź. Jeśli chodzi o pakiety NuGet, dlaczego nadal celujemy w IIS 6 / Classic?
Jeremy Cook
104

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:

* 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ą.

Jeremy Cook
źródło
Rozwiązanie +1 tylko nie jest odpowiedzią na twój problem, ale rozwiązaniem z wyjaśnieniem, które jest idealną odpowiedzią. Co to jest i dlaczego musimy to zmienić, te pytania odpowiedzi udzielone przez @Jeremy cook odpowiedź.
Rikin Patel
To wyjaśnienie doprowadziło mnie do rozwiązania problemu dla małej witryny testowej hostowanej w IIS 7.5 w trybie zintegrowanym. Kiedy utworzyłem nowy projekt MVC, dodałem httpModule, Microsoft.ApplicationInsights.Web.ApplicationInsightsHttpModule w moim Web.config. Wynika to z faktu, że pozostawiłem zaznaczoną opcję „Dodaj statystyki aplikacji do projektu” podczas tworzenia nowego projektu aplikacji ASP.NET Web Aapplication. Kiedy usunąłem httpModule z Web.config, strona działała bez błędu. Ustawienie wartości validateIntegratedModeConfiguration na false działało, ale było to tylko podejście bandaid.
iCode
2
Wykryto ustawienie ASP.NET, które nie ma zastosowania w trybie zintegrowanego potoku zarządzanego. To kolejny bezużyteczny komunikat o błędzie Microsoft. ASP.net ma tysiące ustawień, ale Microsoft nie pomyślał o włączeniu tego, który powoduje błąd w tekście błędu. MS jest prowadzony przez marketerów, a nie inżynierów, więc nie oczekuj, że sytuacja poprawi się w najbliższym czasie. :-(
Paul McCarthy
35

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>
Ashraf Sayied-Ahmad
źródło
2
Myślę, że właściwość HttpModules w system.web dotyczy ASP 3.5 lub wcześniejszej. W przypadku ASP 4 lub nowszej użyj modułów w system.webserver
Trio Cheung
1
@HoyCheung to właściwie kwestia korzystania z potoku zintegrowanego lub klasycznego, a nie jakiej wersji .Net, która decyduje, czy użyć system.web / httpModules czy system.webServer / modules.
Pauli Østerø
29

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.

Gaʀʀʏ
źródło
3
Uzgodnione - jest to lepsza opcja niż ukrywanie błędu! Upewnij się, że używasz prawidłowej puli aplikacji - powinna być klasyczna, a nie zintegrowana
Swomble
1
Korzystam z programu Visual Studio 2012, w jaki sposób mogę zmienić pulę aplikacji na klasyczną.
10
To nie jest dobre rozwiązanie, jeśli chcesz korzystać ze wszystkich nowych funkcji dostępnych w zintegrowanym rurociągu. To tak, jakby powiedzieć o powrocie do .NET 2.0 z 4.0 z powodu problemu.
Trevor de Koekkoek
Aby to zrobić w Menedżerze IIS, przejdź do Application Poolsdrzewa po lewej stronie, kliknij dwukrotnie pulę, którą chcesz zmienić, i wybierz tryb potoku.
Steve Smith
8

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

Jim Yu
źródło
5

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

Zero
źródło
3

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) :-)

Sudhanshu Mishra
źródło
Dzięki. Dodałem AttributeRouting, w tym pakiet NuGet kontrolera Api Controller, a usunięcie wskazanej sekcji z web.config rozwiązało problem. Jestem jednak trochę zaniepokojony, ponieważ moja aplikacja internetowa MVC używała już .NET Framework 4.5.
Robert Oschler,
2
@RobertOschler, jeśli korzystasz z .NET 4.5, masz już wbudowane routing atrybutów w AFAIK - nie powinieneś potrzebować tego NuGet?
Sudhanshu Mishra
Dzięki i gówno. Dzisiaj upłynęło kilka godzin, aby uzyskać pakiet AttributeRouting z NuGet. Wyciągnąłem go i usunąłem wszystkie „poprawki” kodu, które dodałem, aby działało, i zastąpiłem atrybut Route () interfejsu API sieci Web atrybutem GET (). Działa świetnie. W dzisiejszych czasach naprawdę potrzebujemy systemu eksperckiego, aby pomóc nam z tymi wszystkimi pakietami.
Robert Oschler
2

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.

Paweł
źródło
0

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

naveen rawat
źródło
0

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ć.

Mladen Radosović
źródło
0

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

Otwórz CMDmonit z uprawnieniami administratora.

Biegać : iisreset.

Mam nadzieję że to pomoże.

Shaijut
źródło
-1

Metodą lokalną jest błąd

wizerunek

Hossein Khazai
źródło
7
Nie zmieniaj tego ustawienia, chyba że naprawdę wiesz, co robisz. To prawie nigdy nie jest poprawna odpowiedź.
NickG