Es wurde eine ASP.NET-Einstellung gefunden, die im integrierten Modus für verwaltete Pipelines nicht gilt

Das Hinzufügen von <validation validateIntegratedModeConfiguration="false"/> behebt das Symptom, ist jedoch nicht für alle Umstände geeignet. Nachdem ich dieses Thema mehrmals durchlaufen habe, hoffe ich, anderen zu helfen, das Problem nicht nur zu überwinden, sondern auch zu verstehen. (Was immer wichtiger wird, wenn IIS 6 in Mythos und Gerücht ü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 einzigen Pipeline-Modus, und es entspricht dem von IIS 7+ ruft den "Classic" -Modus auf. Der zweite, neuere und empfohlene Pipeline-Modus für alle Anwendungen, die auf IIS 7+ ausgeführt werden, wird als "integrierter" Modus bezeichnet.

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

• Der Classic-Modus ist auf eine ASP.NET-Pipeline beschränkt, die nicht mit der IIS -Pipeline interagieren kann. Im Wesentlichen kommt eine Anforderung in den Fall. Wenn IIS 6/Classic durch die Serverkonfiguration mitgeteilt wurde, dass ASP.NET damit umgehen kann, übergibt IIS die Anforderung an ASP.NET und macht weiter. Die Bedeutung davon kann einem Beispiel entnommen werden. Wenn ich den Zugriff auf statische Image-Dateien autorisieren würde, wäre ich nicht in der Lage, dies mit einem ASP.NET-Modul zu tun, da die Pipeline IIS 6 diese Anforderungen selbst verarbeitet, und ASP.NET diese Anforderungen nie sieht, weil sie dies tun wurden nie übergeben. * Andererseits ist die Berechtigung, welche Benutzer auf eine .ASPX-Seite zugreifen können, z. B. eine Anfrage für Foo.aspx, selbst in IIS 6/Classic trivial, da IIS diese Anfragen immer weitergibt in die ASP.NET-Pipeline. Im Classic-Modus weiß ASP.NET nicht, was nicht gesagt wurde, und es gibt vieles, was IIS 6/Classic nicht sagt.

• Integrierter Modus wird empfohlen, da ASP.NET-Handler und -Module direkt mit der Pipeline IIS 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 treffen. Dies bedeutet, dass ein ASP.NET-Modul nicht nur Anforderungen an statische Image-Dateien überwachen kann, sondern diese Anforderungen abfangen und Maßnahmen ergreifen kann, indem der Zugriff verweigert wird, die Anforderung protokolliert wird usw.

Überwindung des Fehlers:

1. Wenn Sie eine ältere Anwendung ausführen, die ursprünglich für IIS 6 erstellt wurde, haben Sie sie möglicherweise auf einen neuen Server verschoben. Wenn Sie den Anwendungspool dieser Anwendung im klassischen Modus ausführen, kann es absolut nichts dagegen geben. Gehen Sie voran, Sie müssen sich nicht schlecht fühlen.

2. Möglicherweise geben Sie Ihrer Anwendung jedoch ein Facelifting, oder es ruckelt so lange, bis Sie eine Drittanbieter-Bibliothek über NuGet, manuell oder auf andere Weise installiert haben. In diesem Fall ist es durchaus möglich, dass httpHandlers oder httpModules zu system.web hinzugefügt wurden. Das Ergebnis ist der Fehler, den Sie sehen, weil validateIntegratedModeConfigurationtrue verwendet. Jetzt haben Sie zwei Möglichkeiten:

   1. Entfernen Sie die httpHandlers- und httpModules-Elemente aus system.web. Daraus ergeben sich ein paar 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 httpHandlers und httpModules, die NuGet-Pakete zu system.web hinzufügen, zu entfernen, und tun Sie, was Sie brauchen.
3. Wenn diese Optionen nicht funktionieren oder mehr Probleme verursachen, als es wert ist, werde ich Ihnen nicht sagen, dass Sie validateIntegratedModeConfiguration nicht auf false setzen können, aber zumindest wissen Sie, was Sie tun und warum es wichtig ist.

Gut liest:

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

* Natürlich gibt es Möglichkeiten, alle möglichen seltsamen Dinge in die ASP.NET-Pipeline von IIS 6/Classic über Beschwörungen wie Wildcard-Mappings aufzunehmen, wenn Ihnen diese Art von Sachen gefällt.

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. Dazu wurde der Control Panel>Administrative Tools>IIS Manager aktualisiert und die verwaltete Pipeline meiner App-Site von Integrated auf Classic zurückgesetzt.

Prüfen Sie, ob bei Ihrer IIS - Authentifizierung ein Konflikt vorliegt. Sie aktivieren also die anonyme Authentifizierung und den ASP.NET-Identitätswechsel. Beide können ebenfalls den Fehler verursachen.

Vergewissern Sie sich in Ihrer web.config, dass diese Schlüssel vorhanden sind:

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

Sowie die Asp.Net Impresonation = Deaktivieren In IIS Site Authetication 

Das hat für mich funktioniert:

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

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

Ich stieß auf dieses Problem und wurde von @Jeremy Cooks Antwort inspiriert. Ich biss in die Kugel, um herauszufinden, was der Teufel verursacht hatte IIS 7 Integrierter Modus, der meine web.config nicht gefällt. Hier ist mein Szenario:

1. Web-API (Version 4.0.030506.0 oder früher)
2. .NET 4.0
3. Attribut-Routing 3.5.6 für Web-API [Spoiler-Warnung: Es war dieser Typ!]

Ich wollte das 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 wohlmeinende NuGet-Paket fügte diesen Abschnitt im Abschnitt <system.web> hinzu:

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

[Ich sage gut, weil dieser Teil in älteren Versionen von IIS erforderlich ist.]

Das Entfernen dieses Abschnitts hat mich an HTTP 500.23 vorbei geführt !!

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

Ich habe einige Stunden gebraucht, um das Problem zu lösen, da alle Einstellungen, die ich zu diesem Fehler gefunden hatte, identisch waren, aber es funktionierte immer noch nicht. Das Problem war, dass ich einen Ordner in meinem Web-Service hatte, von dem die Datei an das WinCE-Gerät gesendet werden sollte, nachdem dieser Ordner in eine Anwendung mit Classic.NetAppPool konvertiert wurde, mit der er zu arbeiten begann.

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

Vielen Dank