Aug 222014
 

Es gibt Sachen an denen könnte man verzweifeln. Aktuell mache ich ein paar Experimente mit Android, Azure und ASP.NET Web API. Im Web API habe ich eine Methode die scheinbar einwandfrei ausgeführt wird.

Die Methode geht wunderbar in die CreateResponse rein. Auf seiten Android wird mir dann aber von Retrofit ein Error gemeldet. Ein Error der mir gewaltig weiter hilft. 🙁

Man sieht zwar die Meldung {„message“:“Could not save to the database.“}, aber auf dem Server kam ich ohne Fehler bis zu db.SaveChangesAsync();. Was also soll den bitte da schief gegangen sein.

Bei WCF konnte man extrem viel an Login einschalten. Wenn man mal wusste wie mit dem Logfile zu arbeiten ist, hatte man ein mächtiges Werkzeug zur Hand. Aber beim Web API?

Kurz Googlen. Auch beim Web API kann man ziemlich ausgiebiges Tracing einschalten. Beim Debuggen auf Azure wird das dann sogar im Output vom Visual Studio ausgegeben. Die ganze Geschichte ist in zwei Schritten eingerichtet.

  1. Via NuGet wird das Package „Microsoft ASP.NET Web API 2.2 Tracing“ hinzugefügt.
  2. In der Datei WebApiConfig.cs (/App_Start/WebApiConfig.cs) fügt man noch folgende Zeile Code ein.

Und schon sieht man den Fehler im Output Fenster von Visual Studio. War/ist ein blöder Fehler. Schlicht ein Feld das null war.

Ach ja. Auf Azure habe ich alles mögliche an Loging eingeschaltet. Alles was ich gefunden habe. Allerdings bin ich in den entstandenen Logdateien auf keinen Hinweis gestossen. Nur via diesem Tracing war der Fall schnell klar.

  4 Responses to “ASP.NET Web API – Erweitertes Tracing einschalten”

Comments (4)
  1. Die Fehlermeldung ist nicht sehr genau, weil der try-Block mehr als nur Datenbank-Verarbeitung umfasst. Beim Verschlucken von Exceptions kommt es schnell dazu, dass der try-Block einige unvorhergesehene Operationen umfasst.

    Selbst Code, der eigentlich nicht fehlschlagen kann, kann wegen Bugs doch fehlschlagen. Sogar x+1 kann wegen Overflow fehlschlagen. Wenn man Fehler geziehlt abfängt und sie behandeln möchte passiert sowas sehr leicht.

    • Die Exception im Code wird nicht ausgelöst. Die Ausgabe ist nur Tracing die mir anzeigte was am zu sendenden Objekt nicht stimmt. Das db.SaveChangesAsync(); läuft einwandfrei durch. Auch das return Request.CreateResponse(HttpStatusCode.OK, orgDevice); verursachte keine Exception. Somit bekam ich NULL Informationen.
      Oder Verstehe ich deine Aussage falsch?

      • Dann verstehe ich vielleicht etwas nicht. Wie kann denn die Ausgabe „Could not save to the database.“ erscheinen, wenn keine Exception ausgelöst wurde? Mir schien, dass

        Trace.WriteLine(ex.GetExceptionDetails());

        den Trace-Output generiert hatte.

        • Die Ausgabe w3wp.exe Error: 0 : Operation=Js wird nicht von Trace.WriteLine( generiert sondern von config.EnableSystemDiagnosticsTracing(); und kommt somit direkt vom Webserver. Der kann das JSON nicht serialisieren was nicht unbedingt in einer abfangbaren Exception enden muss.

          Das gibt es auch oft beim WCF. Du schickst einen neuen Datentyp über den WCF und vergisst den in KnownType() zu definieren. Schon funktioniert die ganze Geschichte nicht. Keine Exception. Dann kommt man auch nur noch mit dem Tracing weiter. Dort wird dann was rumgejammert das es einen unbekannten Datentype gäbe. Wenn man mal weiss wie suchen sind das keine grossen Probleme mehr.

          Oder auch Methoden mit gleichem Namen aber anderer Überladung. Gibt keine Exception. Merkt man nur im Trace File.

Sorry, the comment form is closed at this time.