08-10-2024, 00:27
Die Konfiguration einer benutzerdefinierten Fehlerbehandlung für ASP.NET-Anwendungen in IIS ist einer dieser wichtigen Schritte, die jeder Entwickler kennen sollte. Vertraue mir, du möchtest deine Benutzer nicht mit diesen generischen Fehlermeldungen im Stich lassen, die verwirrend oder, schlimmer noch, unhilfreich sein können. Lass uns also durchgehen, wie du deiner Anwendung eine persönlichere Note verleihen kannst, wenn etwas schiefgeht.
Zuerst musst du dir überlegen, wo deine benutzerdefinierten Fehlerseiten liegen werden. Normalerweise richte ich sie im Stammverzeichnis der Anwendung oder in einem speziellen "Error"-Ordner ein. So sind sie leicht zu finden und zu verwalten. Du möchtest vielleicht drei oder vier verschiedene Fehlerseiten erstellen, abhängig von den Statuscodes, die du behandeln möchtest. Gewöhnliche wie 404 (nicht gefunden) oder 500 (Serverfehler) sind ein Muss. Du kannst sogar eine allgemeine Seite für unerwartete Fehler haben, um sicherzustellen, dass die Benutzer nicht auf einer leeren Seite stehen bleiben.
Sobald du deine Fehlerseiten erstellt hast, ist es Zeit, IIS zu konfigurieren. Öffne den IIS-Manager und wähle deine Site aus. Du findest dort Funktionen wie "Fehlerseiten", und dort beginnt die Magie. Wenn du darauf klickst, wirst du mit einer Liste von Standardfehlern konfrontiert, die IIS verwaltet. Es kann anfänglich überwältigend erscheinen, aber du möchtest dich jetzt darauf konzentrieren, deine benutzerdefinierten Seiten hinzuzufügen.
Wenn du eine benutzerdefinierte Fehlerseite für einen bestimmten Statuscode festlegen musst, klicke mit der rechten Maustaste auf das Symbol für diesen Statuscode und wähle "Feature-Einstellungen bearbeiten". Das ist eine Möglichkeit, deine benutzerdefinierte Fehlerseite mit einem HTTP-Status zu verknüpfen. Du erhältst die Option, sie auf deine spezifische Seite festzulegen. Wenn jemand beispielsweise versucht, auf eine Seite zuzugreifen, die nicht existiert, und auf einen 404-Fehler stößt, möchtest du das auf deine "404.html" oder welche Seite auch immer, die du gestaltet hast, verweisen.
Aber hier ist, was ich tue, was dir das Leben erleichtern könnte: Anstatt jede Fehlerseite manuell zu konfigurieren, gehe ich gerne in die web.config-Datei der Anwendung. Du wirst einen Abschnitt sehen, der normalerweise als <system.webServer> bezeichnet wird, und dort kannst du alle deine benutzerdefinierten Fehlereinstellungen auf einmal einfügen.
Normalerweise füge ich einen <httpErrors>-Abschnitt darin hinzu. Innerhalb dessen kannst du jeden Statuscode definieren, den du anpassen möchtest. So könnte es aussehen:
<system.webServer>
<httpErrors errorMode="Custom">
<remove statusCode="404" subStatusCode="-1" />
<error statusCode="404" prefixLanguageFilePath="" path="/ErrorPages/404.html" responseMode="File" />
<remove statusCode="500" subStatusCode="-1" />
<error statusCode="500" prefixLanguageFilePath="" path="/ErrorPages/500.html" responseMode="File" />
</httpErrors>
</system.webServer>
Ich achte immer darauf, den errorMode auf "Custom" zu setzen. Das sagt IIS, dass die Fehlerseiten angezeigt werden sollen, die du definiert hast, anstatt der Standardseiten. Das Attribut "responseMode" ist auch etwas, auf das du achten solltest. Es kann auf "File" gesetzt werden, wenn du auf eine statische HTML-Seite verweist, oder auf "ExecuteURL", wenn du jemals eine URL ausführen und sie dynamisch bearbeiten möchtest, was ziemlich cool ist, wenn du mehr Logik auf der Fehlerseite anwenden musst.
Ein weiterer Punkt, den du berücksichtigen solltest, ist der <customErrors>-Abschnitt unter <system.web>. Dies ist besonders nützlich, wenn du dir Fehler aus ASP.NET selbst ansiehst, wie die, die in deinem Code auftreten. Innerhalbdessen kannst du deine bevorzugten Fehlerseiten für bestimmte Arten von Ausnahmen definieren. So könntest du das konfigurieren:
<system.web>
<customErrors mode="On">
<error statusCode="404" redirect="~/ErrorPages/404.html" />
<error statusCode="500" redirect="~/ErrorPages/500.html" />
</customErrors>
</system.web>
Es gibt einen bedeutenden Unterschied zwischen der Verwendung von <httpErrors> und <customErrors>. Die HTTP-Fehler beziehen sich mehr auf die Serverantworten, während benutzerdefinierte Fehler in die ASP.NET-Pipeline integriert sind. Wenn deine Anwendung Ausnahmen auslöst, möchtest du dort einen Hook, um diese abzufangen.
Während du das einrichtest, halte ich die Benutzererfahrung im Hinterkopf. Wenn deine App auf einen 404-Fehler stößt, begrüße den Benutzer mit einer freundlichen Nachricht. Vielleicht kannst du ein Suchfeld oder Links zur Startseite einfügen. Wenn sie auf einen 500-Fehler stoßen, kann eine beruhigende Nachricht viel bewirken, in der informiert wird, dass das Team Bescheid weiß und sich darum kümmert. Einen Kontaktlink oder ein Ticket-Einreichungsformular hinzuzufügen, kann ebenfalls eine persönliche Note verleihen, sodass sich der Benutzer mehr verbunden und weniger frustriert fühlt.
Sobald du alles in der web.config hast, empfehle ich, die verschiedenen Szenarien zu testen. Du kannst Fehler in deiner Anwendung ganz leicht auslösen, indem du versuchst, URLs aufzurufen, von denen du weißt, dass sie fehlschlagen sollten. Das ist entscheidend; du möchtest sicherstellen, dass deine benutzerdefinierten Seiten korrekt geladen werden und dass die bereitgestellten Informationen nützlich sind. Es ist immer ärgerlich, wenn du Zeit damit verbringst, alles schön einzurichten, und es dann in der Praxis nicht funktioniert!
Vergiss nach dem Testen nicht, den Netzwerk-Tab deines Browsers zu überprüfen (insbesondere wenn du Chrome oder Firefox verwendest), um die zurückgegebenen HTTP-Antworten zu sehen. Die Sichtbarkeit auf Netzwerkebene stellt sicher, dass du alle Probleme im Zusammenhang damit erkennst, wie deine Anwendung die benutzerdefinierten Seiten bereitstellt.
Ein weiterer Tipp: Wenn du anfängst, viele Ausnahmen auf deinen Seiten zu erhalten, erwäge, Logging in deine Fehlerseiten zu integrieren. Indem du dies tust, kannst du Fehler protokollieren, um sie später zu untersuchen, was dir hilft, deine App kontinuierlich zu debuggen und zu verbessern. Es ist eine Sache, schöne Fehlerseiten zu haben, aber zu wissen, was hinter den Kulissen schiefgeht, ist ebenso wichtig.
Zuletzt vergiss nicht die SEO. Eine benutzerdefinierte 404-Seite, die freundlich und hilfreich ist, kann sogar helfen, Benutzer zu halten, indem sie sie zurück zum Hauptinhalt leitet. Eine gute Fehlerseite kann einen verwirrten Besucher in einen entdeckenden Nutzer verwandeln und ihm helfen, mehr von den Angeboten deiner Seite zu finden. Achte nur darauf, die HTTP-Statuscodes korrekt zu behandeln, um Suchmaschinen zufrieden zu stellen.
Das war's eigentlich auch schon. Die benutzerdefinierte Fehlerbehandlung besteht nicht nur darin, Seiten zu erstellen und sie in IIS zu verlinken; es geht darum, die Benutzererfahrung zu verbessern, proaktiv mit Problemen umzugehen und sicherzustellen, dass deine Anwendung selbst in schwierigen Zeiten poliert wirkt. Alles, was es braucht, sind ein paar einfache Einstellungen in IIS und ein wenig Kreativität mit deinen Fehlermeldungen. Du schaffst das!
Ich hoffe, du fandest meinen Beitrag nützlich. Übrigens, hast du eine gute Windows-Server-Backup-Lösung? In diesem Beitrag erkläre ich, wie man Windows Server richtig sichert.
Zuerst musst du dir überlegen, wo deine benutzerdefinierten Fehlerseiten liegen werden. Normalerweise richte ich sie im Stammverzeichnis der Anwendung oder in einem speziellen "Error"-Ordner ein. So sind sie leicht zu finden und zu verwalten. Du möchtest vielleicht drei oder vier verschiedene Fehlerseiten erstellen, abhängig von den Statuscodes, die du behandeln möchtest. Gewöhnliche wie 404 (nicht gefunden) oder 500 (Serverfehler) sind ein Muss. Du kannst sogar eine allgemeine Seite für unerwartete Fehler haben, um sicherzustellen, dass die Benutzer nicht auf einer leeren Seite stehen bleiben.
Sobald du deine Fehlerseiten erstellt hast, ist es Zeit, IIS zu konfigurieren. Öffne den IIS-Manager und wähle deine Site aus. Du findest dort Funktionen wie "Fehlerseiten", und dort beginnt die Magie. Wenn du darauf klickst, wirst du mit einer Liste von Standardfehlern konfrontiert, die IIS verwaltet. Es kann anfänglich überwältigend erscheinen, aber du möchtest dich jetzt darauf konzentrieren, deine benutzerdefinierten Seiten hinzuzufügen.
Wenn du eine benutzerdefinierte Fehlerseite für einen bestimmten Statuscode festlegen musst, klicke mit der rechten Maustaste auf das Symbol für diesen Statuscode und wähle "Feature-Einstellungen bearbeiten". Das ist eine Möglichkeit, deine benutzerdefinierte Fehlerseite mit einem HTTP-Status zu verknüpfen. Du erhältst die Option, sie auf deine spezifische Seite festzulegen. Wenn jemand beispielsweise versucht, auf eine Seite zuzugreifen, die nicht existiert, und auf einen 404-Fehler stößt, möchtest du das auf deine "404.html" oder welche Seite auch immer, die du gestaltet hast, verweisen.
Aber hier ist, was ich tue, was dir das Leben erleichtern könnte: Anstatt jede Fehlerseite manuell zu konfigurieren, gehe ich gerne in die web.config-Datei der Anwendung. Du wirst einen Abschnitt sehen, der normalerweise als <system.webServer> bezeichnet wird, und dort kannst du alle deine benutzerdefinierten Fehlereinstellungen auf einmal einfügen.
Normalerweise füge ich einen <httpErrors>-Abschnitt darin hinzu. Innerhalb dessen kannst du jeden Statuscode definieren, den du anpassen möchtest. So könnte es aussehen:
<system.webServer>
<httpErrors errorMode="Custom">
<remove statusCode="404" subStatusCode="-1" />
<error statusCode="404" prefixLanguageFilePath="" path="/ErrorPages/404.html" responseMode="File" />
<remove statusCode="500" subStatusCode="-1" />
<error statusCode="500" prefixLanguageFilePath="" path="/ErrorPages/500.html" responseMode="File" />
</httpErrors>
</system.webServer>
Ich achte immer darauf, den errorMode auf "Custom" zu setzen. Das sagt IIS, dass die Fehlerseiten angezeigt werden sollen, die du definiert hast, anstatt der Standardseiten. Das Attribut "responseMode" ist auch etwas, auf das du achten solltest. Es kann auf "File" gesetzt werden, wenn du auf eine statische HTML-Seite verweist, oder auf "ExecuteURL", wenn du jemals eine URL ausführen und sie dynamisch bearbeiten möchtest, was ziemlich cool ist, wenn du mehr Logik auf der Fehlerseite anwenden musst.
Ein weiterer Punkt, den du berücksichtigen solltest, ist der <customErrors>-Abschnitt unter <system.web>. Dies ist besonders nützlich, wenn du dir Fehler aus ASP.NET selbst ansiehst, wie die, die in deinem Code auftreten. Innerhalbdessen kannst du deine bevorzugten Fehlerseiten für bestimmte Arten von Ausnahmen definieren. So könntest du das konfigurieren:
<system.web>
<customErrors mode="On">
<error statusCode="404" redirect="~/ErrorPages/404.html" />
<error statusCode="500" redirect="~/ErrorPages/500.html" />
</customErrors>
</system.web>
Es gibt einen bedeutenden Unterschied zwischen der Verwendung von <httpErrors> und <customErrors>. Die HTTP-Fehler beziehen sich mehr auf die Serverantworten, während benutzerdefinierte Fehler in die ASP.NET-Pipeline integriert sind. Wenn deine Anwendung Ausnahmen auslöst, möchtest du dort einen Hook, um diese abzufangen.
Während du das einrichtest, halte ich die Benutzererfahrung im Hinterkopf. Wenn deine App auf einen 404-Fehler stößt, begrüße den Benutzer mit einer freundlichen Nachricht. Vielleicht kannst du ein Suchfeld oder Links zur Startseite einfügen. Wenn sie auf einen 500-Fehler stoßen, kann eine beruhigende Nachricht viel bewirken, in der informiert wird, dass das Team Bescheid weiß und sich darum kümmert. Einen Kontaktlink oder ein Ticket-Einreichungsformular hinzuzufügen, kann ebenfalls eine persönliche Note verleihen, sodass sich der Benutzer mehr verbunden und weniger frustriert fühlt.
Sobald du alles in der web.config hast, empfehle ich, die verschiedenen Szenarien zu testen. Du kannst Fehler in deiner Anwendung ganz leicht auslösen, indem du versuchst, URLs aufzurufen, von denen du weißt, dass sie fehlschlagen sollten. Das ist entscheidend; du möchtest sicherstellen, dass deine benutzerdefinierten Seiten korrekt geladen werden und dass die bereitgestellten Informationen nützlich sind. Es ist immer ärgerlich, wenn du Zeit damit verbringst, alles schön einzurichten, und es dann in der Praxis nicht funktioniert!
Vergiss nach dem Testen nicht, den Netzwerk-Tab deines Browsers zu überprüfen (insbesondere wenn du Chrome oder Firefox verwendest), um die zurückgegebenen HTTP-Antworten zu sehen. Die Sichtbarkeit auf Netzwerkebene stellt sicher, dass du alle Probleme im Zusammenhang damit erkennst, wie deine Anwendung die benutzerdefinierten Seiten bereitstellt.
Ein weiterer Tipp: Wenn du anfängst, viele Ausnahmen auf deinen Seiten zu erhalten, erwäge, Logging in deine Fehlerseiten zu integrieren. Indem du dies tust, kannst du Fehler protokollieren, um sie später zu untersuchen, was dir hilft, deine App kontinuierlich zu debuggen und zu verbessern. Es ist eine Sache, schöne Fehlerseiten zu haben, aber zu wissen, was hinter den Kulissen schiefgeht, ist ebenso wichtig.
Zuletzt vergiss nicht die SEO. Eine benutzerdefinierte 404-Seite, die freundlich und hilfreich ist, kann sogar helfen, Benutzer zu halten, indem sie sie zurück zum Hauptinhalt leitet. Eine gute Fehlerseite kann einen verwirrten Besucher in einen entdeckenden Nutzer verwandeln und ihm helfen, mehr von den Angeboten deiner Seite zu finden. Achte nur darauf, die HTTP-Statuscodes korrekt zu behandeln, um Suchmaschinen zufrieden zu stellen.
Das war's eigentlich auch schon. Die benutzerdefinierte Fehlerbehandlung besteht nicht nur darin, Seiten zu erstellen und sie in IIS zu verlinken; es geht darum, die Benutzererfahrung zu verbessern, proaktiv mit Problemen umzugehen und sicherzustellen, dass deine Anwendung selbst in schwierigen Zeiten poliert wirkt. Alles, was es braucht, sind ein paar einfache Einstellungen in IIS und ein wenig Kreativität mit deinen Fehlermeldungen. Du schaffst das!
Ich hoffe, du fandest meinen Beitrag nützlich. Übrigens, hast du eine gute Windows-Server-Backup-Lösung? In diesem Beitrag erkläre ich, wie man Windows Server richtig sichert.
