ASP.NET MVC: Content bei 4xx Antworten zurückgeben

Wenn man in einer Action einen HTTP-Fehler generiert, dann setzt der IIS als Content immer seine Standardmeldung.

Beispiel:

public ActionResult MyAction()
{
    Response.StatusCode = 409; // Conflict
    return Content("A steht mit B im Konflikt!", "text/plain")
}

Die Antwort die man beim Abruf der Action kriegt ist nicht wie zu erwarten "A steht mit B im Konflikt!", sondern "Seite kann aufgrund eines Konfliktes nicht angezeigt werden", wobei die Sprache der Meldung abhängig Ländereinstellung des Servers ist.

Die Lösung: Response.TrySkipIisCustomErrors = true;

public ActionResult MyAction()
{
    Response.StatusCode = 409; // Conflict
    Response.TrySkipIisCustomErrors = true;
    return Content("A steht mit B im Konflikt!", "text/plain")
}

Error 405 bei HttpDelete Requests

Wenn in einer Web-Anwendung auf einem IIS 7.5 bei HttpDelete Requests der Fehler Code 405 auftritt ist das meist ein Indiz dafür, dass das standardmäßig beim IIS 7.5 installierte WebDav Modul dazwischen funkt.
Dieses sollte dann in der web.config wie folgt ausgesachaltet werden:

<modules runAllManagedModulesForAllRequests="true">
    <remove name="WebDAVModule" />
</modules>

Siehe auch:  http://stackoverflow.com/questions/1760607/asp-net-mvc-got-405-error-on-http-delete-request

Server.MapPath() mal anders

Server.MapPath(...) ist bekanntlich eine praktische Methode, um in Controllern und Views physische Pfade für Assets zu bestimmen.

Und wenn man kein Server-Objekt hat?

Sofern der Code im Rahmen eines Requests ausgeführt wird kann man einfach über den HttpContext gehen:

HttpContext.Current.Server.MapPath(...)

Was aber, wenn man z.B. in einem statischen Konstruktor oder sonst wie außerhalb eines Requests einen Pfad bestimmen muss. Auch hier gibt es eine Lösung:

HostingEnvironment.MapPath(...)

Prinzipiell könnte man wohl an allen Stellen an denen man Server.MapPath(...) verwendet auch HostingEnvironment.MapPath(...) nehmen.