using System.Web.Mvc.Html;

Es ist nur eine kleine Sache, aber es kann je nach dem dauern, bis man darauf kommt (wie bei mir heute…):

Wenn man eine neue Extension Method für HtmlHelper schreiben will, z.B. einen speziell „konfigurierte“ Variante von Html.ActionLink, sind Methoden wie eben ActionLink erst sichtbar, wenn man neben System.Web.Mvc auch System.Web.Mvc.Html importiert.

Man kommt deshalb so schlecht drauf, weil Visual Studio 2010 nicht genügend schlau ist, auf diese Tatsache hinzuweisen, wenn man im Code htmlHelper.ActionLink hinschreibt, bzw. der „using“-Assistent findet zwar heraus, dass man für einen HtmlHelper einen Import von System.Web.Mvc benötigt, versagt aber für ActionLink und ähnliche Methoden.

Eigene Fehlerseiten in ASP.NET MVC2

Heute wollte ich in der ASP.NET-MVC2-Web-Applikation, an der ich gerade arbeite, eigene Fehlerseiten einrichten, vor allem natürlich für den HTTP-Fehler 404.

Auf den ersten Blick sieht alles ziemlich einfach aus, denn solche eigene Fehlerseiten sind ein häufig benötigtes Feature, und die Erbauer von MVC haben entsprechend etwas bereitgestellt: Die Stichworte sind da Einsatz des HandleErrorAttribute im Code und customErrors in web.config, bei Microsoft z.B. hier beschrieben.

Rein optisch sieht das Resultat im Browser perfekt aus, bei Fehler kommt die eigene Seite, die man nach Belieben selbst gestalten kann. Die Sache hat aber einen ziemlich grossen Schönheitsfehler: Der Webserver liefert die Fehlerseite nicht mit dem Fehler als Statuscode aus, sondern mit Code 200 „alles in Ordnung“. Das ist im besten Fall einfach Unsinn und führt im schlimmsten Fall dazu, dass Roboter von Suchmaschinen beim Abklappern der Website ein ziemlich schiefes Bild davon bekommen.

Bei meiner Suche im Internet nach einer Lösung für dieses Problem kam ich dann ganz schön ins Staunen: Ich glaube, ich habe noch nie einen solchen Wildwuchs von Lösungen und Lösungsversuchen betreffend MVC angetroffen wie bei dieser Sache! Eine Auswahl von dem, was ich gefunden habe:

Dieser Artikel beschreibt das Problem ausführlich und schlägt eine Lösung vor, die etwas kompliziert aussieht und zudem schon etwas älter zu sein scheint. Dieser Artikel zählt eine lange Liste diverser Eingriffe auf, bei denen wohl die Meinung sein soll, sie seien alle nötig, damit es sicher mit jeder Kombination von Framework und IIS klappt, was mir etwas unwahrscheinlich erschien.

Implementiert habe ich schliesslich die hier beschriebene Lösung, die up-to-date, einfach und übersichtlich ist und an der ich (bis jetzt zumindest) trotzdem keinen Haken finden konnte; kann ich also empfehlen.

Diese Lösung klappt übrigens nicht nur mit dem Wert On für den Parameter mode bei customErrors, sondern ebensogut mit RemoteOnly, was für das Debugging gewisse Vorteile haben kann.