Ich habe DotNetOpenAuth SDK-3.4.5.10201.vsix installiert und kann es nicht zum Laufen bringen .. Es funktioniert lokal (wenn ich als localhost aktiv bin), aber wenn ich versuche, es zu veröffentlichen, funktioniert es nicht.
Die Fehlermeldung IIS wird angezeigt
Fehlerzusammenfassung
HTTP-Fehler 500.22 - Interner Serverfehler
Es wurde eine ASP.NET-Einstellung gefunden, die im integrierten Modus für verwaltete Pipelines nicht gilt.
UND
Module ConfigurationValidationModule Notification BeginRequest Handler StaticFile Error Code 0x80070032
dann gibt es einige Vorschläge, wie das Problem gelöst werden kann:
Dinge, die Sie ausprobieren können:
Migrieren Sie die Konfiguration in die
system.webServer/modules
Abschnitt. Sie Dies kann manuell oder mithilfe von AppCmd .__ erfolgen. von der Befehlszeile aus - zum Beispiel%SystemRoot%\system32\inetsrv\appcmd migrate config "Default Web Site/"
.AppCmd
verwenden, um Ihre .__ zu migrieren. Anwendung wird es ermöglichen, in .__ zu arbeiten. Integrierter Modus und weiterarbeiten im klassischen Modus und auf dem vorherigen Versionen von IIS.Wenn Sie sicher sind, dass es OK ist, Ignorieren Sie diesen Fehler, es kann deaktiviert werden indem man es einstellt
system.webServer/[email protected]
zu falschWechseln Sie alternativ die Anwendung zu einem Anwendungspool im klassischen Modus - zum Beispiel,
%SystemRoot%\system32\inetsrv\appcmd set app "Default Web Site/" /applicationPool:"Classic .NET AppPool"
. Tun Sie dies nur, wenn Sie .__ sind. Ihre Anwendung kann nicht migriert werden.
(Legen Sie "Standardwebsite" und "Classic .NET AppPool" auf Ihren Anwendungspfad und den Namen des Anwendungspools fest.)
Das Problem ist jedoch, dass ich keinen Zugriff auf den ISS Server habe, da ich nicht der Besitzer des Servers bin. Gibt es eine Möglichkeit, dies zu lösen?
Die 2nd Option ist die, die Sie wollen.
Stellen Sie in Ihrem web.config
sicher, dass diese Schlüssel vorhanden sind:
<configuration>
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
</system.webServer>
</configuration>
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:
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 validateIntegratedModeConfiguration
true
verwendet. Jetzt haben Sie zwei Möglichkeiten:
httpHandlers
- und httpModules
-Elemente aus system.web
. Daraus ergeben sich ein paar mögliche Ergebnisse: httpHandlers
und httpModules
, die NuGet-Pakete zu system.web
hinzufügen, zu entfernen, und tun Sie, was Sie brauchen.validateIntegratedModeConfiguration
nicht auf false
setzen können, aber zumindest wissen Sie, was Sie tun und warum es wichtig ist.Gut liest:
* 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:
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:
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