Wir haben eine in klassischen ASP-Anwendungen geschriebene Anwendung auf Azure-Websites (gemeinsam genutzt) migriert und einige Seiten geben einfach den Fehler "Die Seite kann nicht angezeigt werden, da ein interner Serverfehler aufgetreten ist." ohne irgendwelche Details. Diese Seiten funktionieren gut unter IIS 7 oder mit IIS express. Wie auch immer auf der Azure-Website tun sie dies nicht.
Wie in einigen anderen Beiträgen vorgeschlagen, habe ich Folgendes für die Website auf Azure konfiguriert:
1) Webserver-Protokollierung - EIN
2) Detaillierte Fehlermeldungen - EIN
3) Web.config - customErrors-Modus deaktiviert.
<customErrors mode="Off"/>
<compilation debug="true" targetFramework="4.0">
Die Protokollnachrichten enthalten jedoch keine weiteren Details, was falsch ist, und geben lediglich die folgenden Informationen an:
Detaillierte Fehlerinformationen:
Modul IsapiModule
Benachrichtigung ExecuteRequestHandler
Handler ASPClassic
Fehlercode 0x00000000
Jede Hilfe wird geschätzt, um die klassischen Asp-Seiten-Probleme auf Azure-Websites zu beheben. Vielen Dank.
Möglicherweise liegt Ihr Problem auf der Browserseite: Stellen Sie sicher, dass die Einstellung "IE" Freundschaftsanzeigen anzeigen] deaktiviert ist
Auf der Serverseite müssen Sie außerdem über Einstellungen verfügen, die das Senden von Fehlernachrichten an den Client zulassen. (Leider habe ich nur Zugriff auf den IIS -Parameter dieser Einstellung ... nicht sicher, was in Azure enthalten ist.) :
Vielen Dank an G. Stoynev! Es funktionierte nach dem Hinzufügen der benutzerdefinierten Fehler-Asp-Seite! Ich habe den Code aus dem folgenden Link verwendet, um eine benutzerdefinierte Fehler-Asp-Seite zu erstellen
http://support.Microsoft.com/kb/224070
Auch der folgende Link hat geholfen http://www.tacticaltechnique.com/web-development/classic-asp-getlasterror-in-iis7/
Nun sieht der Abschnitt system.webServer in meiner web.config wie folgt aus:
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
<modules runAllManagedModulesForAllRequests="true"/>
<httpErrors>
<remove statusCode="500" subStatusCode="100" />
<error statusCode="500" subStatusCode="100" prefixLanguageFilePath="" path="/errors.asp" responseMode="ExecuteURL" />
</httpErrors>
</system.webServer>
Eine (seltsame) Sache, die ich probieren sollte, die für mich funktioniert hat:
Versuchen Sie, per FTP auf Ihre Azure-Website zuzugreifen, und geben Sie Ihrem web.config
einen völlig anderen Namen.
Ich habe meine in web.config2
umbenannt - die Azure "The page cannot be displayed because an internal server error has occurred."
-Fehlermeldung verschwand, und meine ASP.Net-Anwendung wurde wieder lebendig.
Von dort aus habe ich die web.config von Grund auf neu erstellt und Stück für Stück aus meiner Originalversion kopiert (um zu sehen, was das Problem verursacht hat)
Ja, ich weiß ... es ist ein dummer Vorschlag, aber Azure gab mir keine Hinweise darauf, was den Fehler verursacht hatte, selbst wenn die Protokollierung eingeschaltet war, und dies rettete meinen Verstand !!
Damit die detaillierten Fehlermeldungen an den Browser gesendet werden, müssen Sie das Attribut scriptErrorSentToBrowser wie folgt aktivieren.
<system.webServer>
<asp scriptErrorSentToBrowser="true" />
</system.webServer>
Es versteht sich von selbst, dass dies ein potenzielles Sicherheitsrisiko darstellen kann und sollte daher nicht aktiviert bleiben!
Ich habe das Problem gelöst, indem Sie das Anwendungsprotokoll unter Protokollierung => Diagnoseprotokoll in der Konfiguration der Azure-Webanwendung aktivieren.
Sie können den Fehler dann im Bereich "Log Stream" sehen und beheben.
In meinem Fall war der Fehler die folgenden zwei Zeilen im web.config
:
<add name="ExtensionlessUrlHandler-Integrated-4.0"
path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler"
preCondition="integratedMode,runtimeVersionv4.0"/>
<remove name="ExtensionlessUrlHandler-Integrated-4.0"/>
Ich entfernte sie und es funktionierte wieder.
Wenn Sie versuchen, Ihre Site zu konfigurieren, auf der Sie keinen Zugriff auf IIS haben, z. B. eine Azure-Webanwendung, können Sie die Einstellungen für Classic ASP in Web.Config konfigurieren.
Unter
<system.webServer>
Sie können eine platzieren
<asp>
element, das verschiedene Dinge mit der Funktionsweise von Classic konfiguriert.
Die Eigenschaft, die sich auf meine Website auswirkte, war
**appAllowDebugging="true"**
Diese Eigenschaft ist zwar gut und schlecht, wenn Sie mit Visual Studio entwickeln und einen Just-In-Time-Debugger installiert haben. Dadurch wird jedoch die Fehlerbehandlung für Classic Asp beeinträchtigt.
Übrigens, ich habe ewig gebraucht, um herauszufinden, was ich geändert habe.