Es wurde eine ASP.NET-Einstellung erkannt, die im integrierten verwalteten Pipeline-Modus nicht gilt

Ich habe DotNetOpenAuth SDK-3.4.5.10201.vsix installiert und kann es nicht zum Laufen bringen. Es funktioniert lokal (wenn ich als localhost ausgeführt werde), aber wenn ich versuche, es zu veröffentlichen, funktioniert es nicht.

Die IIS-Fehlermeldung, die ich erhalte, lautet

Fehler Zusammenfassung
HTTP - Fehler 500,22 - Internal Server Error
Ein ASP.NET - Einstellung erkannt wurde , die in Integrated gilt nicht verwalteten Pipelinemodus.

UND

Module       ConfigurationValidationModule  
Notification BeginRequest  
Handler      StaticFile  
Error Code   0x80070032  

Dann gibt es einige Vorschläge zur Lösung des Problems:

Dinge, die Sie ausprobieren können:

• Migrieren Sie die Konfiguration in den system.webServer/modulesAbschnitt. Sie können dies manuell oder mithilfe von AppCmd ​​über die Befehlszeile tun, z %SystemRoot%\system32\inetsrv\appcmd migrate config "Default Web Site/". Wenn Sie AppCmdIhre Anwendung migrieren, kann sie im integrierten Modus arbeiten und im klassischen Modus und in früheren Versionen von IIS weiterarbeiten.

• Wenn Sie sicher sind, dass es in Ordnung ist, diesen Fehler zu ignorieren, kann er durch Setzen system.webServer/validation@validateIntegratedModeConfiguration auf false deaktiviert werden .

• Alternativ können Sie die Anwendung in einen Anwendungspool im klassischen Modus wechseln, z %SystemRoot%\system32\inetsrv\appcmd set app "Default Web Site/" /applicationPool:"Classic .NET AppPool". Tun Sie dies nur, wenn Sie Ihre Anwendung nicht migrieren können.
  (Setzen Sie "Standardwebsite" und "Classic .NET AppPool" auf Ihren Anwendungspfad und den Namen des Anwendungspools.)

Das Problem ist jedoch, dass ich keinen Zugriff auf den ISS-Server habe, da ich nicht dessen Eigentümer bin. Gibt es eine Möglichkeit, dies zu lösen?

Die 2 ^nd Option ist diejenige , die Sie wollen.

Stellen Sie in Ihrem web.configsicher, dass diese Schlüssel vorhanden sind:

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

Das Hinzufügen <validation validateIntegratedModeConfiguration="false"/>behebt das Symptom, ist jedoch nicht für alle Umstände geeignet. Nachdem ich dieses Problem einige Male umgangen habe, hoffe ich, anderen zu helfen, das Problem nicht nur zu überwinden, sondern es auch zu verstehen. (Was immer wichtiger wird, wenn IIS 6 in Mythen und Gerüchte übergeht.)

Hintergrund:

Dieses Problem und die damit verbundene Verwirrung begannen mit der Einführung von ASP.NET 2.0 und IIS 7. IIS 6 hatte und hat nur einen Pipeline-Modus und entspricht dem, was IIS 7+ als "klassischen" Modus bezeichnet. Der zweite, neuere und empfohlene Pipeline-Modus für alle Anwendungen, die unter IIS 7+ ausgeführt werden, wird als "Integrierter" Modus bezeichnet.

Also, was ist der Unterschied? Der Hauptunterschied besteht darin, wie ASP.NET mit IIS interagiert.

• Klassischer Modusist auf eine ASP.NET-Pipeline beschränkt, die nicht mit der IIS-Pipeline interagieren kann. Im Wesentlichen geht eine Anforderung ein, und wenn IIS 6 / Classic über die Serverkonfiguration mitgeteilt wurde, dass ASP.NET diese verarbeiten kann, gibt IIS die Anforderung an ASP.NET weiter und fährt fort. Die Bedeutung davon kann einem Beispiel entnommen werden. Wenn ich den Zugriff auf statische Bilddateien autorisieren würde, wäre dies mit einem ASP.NET-Modul nicht möglich, da die IIS 6-Pipeline diese Anforderungen selbst verarbeitet und ASP.NET diese Anforderungen niemals sieht, da sie nie übergeben wurden . * Andererseits ist es selbst in IIS 6 / Classic trivial, zu autorisieren, welche Benutzer auf eine ASPX-Seite wie eine Anforderung für Foo.aspx zugreifen können, da IIS diese Anforderungen immer an die ASP.NET-Pipeline weitergibt. Im klassischen Modus weiß ASP.NET nicht, was es nicht hat.

• Der integrierte Modus wird empfohlen, da ASP.NET-Handler und -Module direkt mit der IIS-Pipeline interagieren können. Die IIS-Pipeline übergibt die Anforderung nicht mehr einfach an die ASP.NET-Pipeline. Jetzt kann ASP.NET-Code direkt in die IIS-Pipeline und alle Anforderungen eingebunden werden, die sie getroffen haben. Dies bedeutet, dass ein ASP.NET-Modul nicht nur Anforderungen an statische Bilddateien beobachten kann, sondern diese Anforderungen auch abfangen und Maßnahmen ergreifen kann, indem der Zugriff verweigert, die Anforderung protokolliert usw. wird.

Fehler überwinden:

1. Wenn Sie eine ältere Anwendung ausführen, die ursprünglich für IIS 6 erstellt wurde, Sie sie möglicherweise auf einen neuen Server verschoben haben, ist möglicherweise absolut nichts falsch daran, den Anwendungspool dieser Anwendung im klassischen Modus auszuführen. Du musst dich nicht schlecht fühlen.

2. Andererseits geben Sie Ihrer Anwendung möglicherweise ein Facelifting oder sie tuckerte einwandfrei, bis Sie eine Bibliothek eines Drittanbieters über NuGet manuell oder auf andere Weise installiert haben. In diesem Fall ist es durchaus möglich httpHandlersoder httpModuleswurde hinzugefügt system.web. Das Ergebnis ist der Fehler, den Sie aufgrund der validateIntegratedModeConfigurationStandardeinstellungen sehen true. Jetzt haben Sie zwei Möglichkeiten:

   1. Entfernen Sie die httpHandlersund httpModulesElemente aus system.web. Daraus ergeben sich einige mögliche Ergebnisse:
      • Alles funktioniert gut, ein gemeinsames Ergebnis;
      • Ihre Anwendung beschwert sich weiterhin. Möglicherweise befindet sich in einem übergeordneten Ordner, von dem Sie erben, eine web.config. Bereinigen Sie auch diese web.config.
      • Sie werden es leid, die httpHandlersund httpModulesdie NuGet-Pakete zu entfernen, und system.webtun, was Sie brauchen.
3. Wenn diese Optionen nicht funktionieren oder sind mehr Mühe , als es wert ist , dann bin ich nicht , dass Sie gehen zu sagen , dass Sie nicht einstellen validateIntegratedModeConfigurationzu false, aber zumindest wissen Sie , was Sie tun und warum es wichtig ist .

Gut liest:

• ASP.NET 2.0 Unterbrechen von Änderungen in IIS 7.0
• ASP.NET-Integration mit IIS 7
• Übersicht über HTTP-Handler und HTTP-Module

* Natürlich gibt es Möglichkeiten, alle möglichen seltsamen Dinge von IIS 6 / Classic über Beschwörungsformeln wie Platzhalterzuordnungen in die ASP.NET-Pipeline zu integrieren , wenn Sie solche Dinge mögen.

Wenn Sie das HTTP-Modul weiterhin verwenden müssen, müssen Sie es (.NET 4.0-Framework) wie folgt konfigurieren:

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

Ich bin auf dieses Problem gestoßen, hatte aber eine andere Lösung. Es beinhaltete das Aktualisieren Control Panel>Administrative Tools>IIS Managerund Zurücksetzen der verwalteten Pipeline meiner App-Site von Integratedauf Classic.

Überprüfen Sie, ob bei Ihrer IIS-Authentifizierung ein Konflikt vorliegt. Wenn Sie also die anonyme Authentifizierung und den ASP.NET-Identitätswechsel aktivieren, kann der Fehler ebenfalls auftreten.

Stellen Sie in Ihrer web.config sicher, dass diese Schlüssel vorhanden sind:

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

Überprüfen Sie außerdem die Option Asp.Net Impresonation = In IIS Site Authetication deaktivieren

Ich bin auf dieses Problem gestoßen und habe mich von der Antwort von @Jeremy Cook inspirieren lassen. Ich habe in die Kugel gebissen, um herauszufinden, was zum Teufel dazu geführt hat, dass der integrierte IIS 7-Modus meine web.config nicht mag. Hier ist mein Szenario:

1. Web-API (Version 4.0.030506.0, auch bekannt als die alte)
2. .NET 4.0
3. Attribut-Routing 3.5.6 für die Web-API [Spoiler-Warnung: Es war dieser Typ!]

Ich wollte Attribut-Routing in einem Projekt verwenden, das (leider) .NET 4 verwenden musste und daher die Web-API 2.2 (die .NET 4.5 benötigt) nicht verwenden konnte. Das gut gemeinte NuGet-Paket hat diesen Abschnitt unter dem <system.web>Abschnitt hinzugefügt :

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

[Ich sage gut gemeint, weil dieser Teil für ältere Versionen von IIS erforderlich ist]

Durch das Entfernen dieses Abschnitts bin ich am HTTP 500.23 vorbeigekommen !!

Zusammenfassung: Ich stimme Jeremys Worten zu, dass es wichtig ist zu verstehen, warum Dinge nicht funktionieren, anstatt nur "das Symptom zu maskieren". Selbst wenn Sie das Symptom maskieren müssen, wissen Sie, was Sie tun (und warum) :-)

Das hat bei mir funktioniert:

1. Löschen Sie die ursprünglich erstellte Site.
2. Erstellen Sie die Site in IIS neu
3. Saubere Lösung
4. Lösung erstellen

Es scheint, als wäre etwas nach Süden gegangen, als ich die Seite ursprünglich erstellt habe. Ich hasse Lösungen, die ähnlich sind wie "Starten Sie Ihren Computer neu und installieren Sie dann Windows neu", ohne zu wissen, was den Fehler verursacht hat. Aber das hat bei mir funktioniert. Schnell und einfach. Hoffe es hilft jemand anderem.

In meinem Fall fehlte mir die DLL im Ordner bin, auf den in der Datei web.config verwiesen wurde. Überprüfen Sie also, ob Sie eine Einstellung in web.config verwendet haben, aber tatsächlich keine DLL haben.

Vielen Dank

Ich habe einige Stunden gebraucht, um das Problem zu beheben, da alle Einstellungen, die ich hier zu diesem Fehler gefunden habe, gleich waren, aber immer noch nicht funktionierten. Das Problem war, dass ich einen Ordner in meinem Webdienst hatte, von dem aus die Datei an das WinCE-Gerät gesendet werden sollte, nachdem dieser Ordner in eine Anwendung mit Classic.NetAppPool konvertiert wurde, begann er zu funktionieren.

Der folgende Schritt hat mein Problem gelöst:

Öffnen Sie die CMDEingabeaufforderung mit Administratorrechten.

Lauf : iisreset.

Hoffe das hilft.

Die Methode für local ist der Fehler