Früher oder später kommt jeder Entwickler in die Situation, seine mühsam erstellte Anwendung wegen eines Fehlverhaltens im Debugger genauer inspizieren zu müssen. In meinem Fall wollte eine Windows Phone 8-Anwendung einfach nicht mit einem Web Service sprechen, obwohl nach allem Dafürhalten die clientseitige Implementierung korrekt aussah. Nun ist das Debuggen, und insbesondere das Debuggen von Netzwerktraffic in diesem Bereich nicht ganz so trivial wie bei gewöhnlichen Desktop-Anwendungen. Aber mit heutigen Werkzeugen und sonstigen Hilfsmitteln ist es auch kein Hexenwerk. Dachte ich.
Die eigentliche Problematik ergibt sich gerade im speziellen Fall der Netzwerk-Kommunikation und Web Services häufig erst aus den inhärenten Sicherheitsmechanismen, die z.B. Details der serverseitigen Implementierung im Fehlerfall vor potenziellen Angreifern verstecken sollen. Kaum ein Silverlight- oder Phone-Entwickler, der nicht schon mit perplexer Miene auf die legendäre Fehlermeldung "NotFound" starrte und erstmal nicht weiter wusste. Zwar ist es nicht ratsam, Stack Traces oder ähnliche Detailinformationen ungeprüft an Clients weiterzureichen. Für Debugging-Zwecke kann man das aber natürlich trotzdem tun, im Falle von SOAP-Services z.B. durch sogenannte Undeclared Faults [1]. Manchmal liegt aber die serverseitige Konfiguration außerhalb der eigenen Reichweite, oder aber man möchte die Infrastruktur genauer untersuchen, z.B. um Caching-Verhalten oder dynamische Kompression zu untersuchen, was durch solche Konfigurationen nicht abgedeckt werden kann – ein Netzwerk-Sniffer muss her!
Fiddler und Windows Phone
In den letzten Jahren hat sich Fiddler (http://www.fiddler2.com/fiddler2/) als wertvollstes Werkzeug für die Analyse von HTTP(S)-Netzwerkverkehr herausgestellt. Es hat einen großen Funktionsumfang, der noch durch Plug-Ins erweitert werden kann, macht den Umgang mit der Thematik aber sehr einfach und auch für Einsteiger zugänglich.
Für gewöhnlich funktioniert Fiddler aus gutem Grund nur mit lokal initiiertem Netzwerkverkehr. Beim speziellen Fall Windows Phone ist es nun aber so, dass die Emulatoren virtuelle Maschinen und somit aus Sicht eines solchen Werkzeugs einen separaten Rechner darstellen. Damit man also Netzwerkverkehr von Phone-Anwendungen mitschneiden kann, ist ein wenig Konfigurationsaufwand nötig. Insbesondere muss man Fiddler erlauben, auch Verbindungen von anderen Rechnern im Netz annehmen zu dürfen:
Zusätzlich muss man konfigurieren, dass der eigene Rechnername als Proxy im Netz kundgetan wird. An diese Option gelangt man am komfortabelsten, indem man in der schwarz hinterlegten Schnellbefehlsleiste am linken unteren Rand des Fiddler-Hauptfensters (Shortcut Alt+Q) den Befehl "about:config" eingibt. Es öffnet sich ein neuer Reiter mit allen Konfigurationsoptionen, von denen eine die gewünschte ist (neu anlegen falls nicht vorhanden):
Nach einem Neustart sowohl Fiddlers als auch des Phone-Emulators wird dann dessen Netzwerkverkehr über Fiddler geleitet. Unter Windows Phone 7 funktionierte das problemlos, zu meinem Erstaunen war ich jedoch unter Windows Phone 8 auch weiterhin nicht in der Lage, Netzwerkverkehr mitzuschneiden. Mehr noch, kurze Tests im Browser des Emulators ergaben, dass er überhaupt keinen Zugriff aufs Netz hatte.
Windows Phone 8
Schon vor einiger Zeit habe ich ausführlich darüber geschrieben, wie dramatisch sich Windows Phone 8 im Vergleich zu seinem Vorgänger unter der Haube verändert hat [2]. Dazu gehört auch, dass die Emulatoren nun als Hyper-V-Maschinen angelegt sind. Das ist einer der Gründe, warum als Entwicklungs-Hostsystem nur noch Windows 8 in Frage kommt, und an die Hardware zusätzliche Anforderungen (Unterstützung für SLAT durch die CPU) gestellt sind [3].
Ein Blick in die Detaileigenschaften des Emulators, insbesondere auf die neuen Netzwerkinformationen, offenbarte dann auch, dass der Emulator nur eine 169.254.x.x Adresse verwendete – ein sicherer Indikator dafür, dass keine IP-Adresse per DHCP angefordert werden konnte. Das verwunderte mich nicht wirklich, da im lokalen Netz per MAC-Filter nur bekannten Geräten der Zugang erlaubt wird. Um also den Windows Phone 8-Emulator zu integrieren, musste dessen MAC-Adresse auf die Positivliste des DHCP-Servers gesetzt werden. Die MAC-Adresse erfährt man entweder in den Detailinformationen des Emulators (Reiter "Network"), oder aber über den Hyper-V-Manager, wo die Emulatoren einzeln auftauchen:
Ein weiterer Neustart des Emulators zeigte dann, dass eine IP-Adresse angefordert werden und der Emulator auch erfolgreich im Netzwerk kommunizieren konnte. Der Analyse des Netzwerkverkehrs stand also nichts mehr im Wege.
Fazit
Das Beispiel zeigt, dass die dramatischen Neuerungen der Plattform nicht immer auch zwangsläufig zu einer Vereinfachung für die Entwickler führen müssen. Im Gegensatz zu dem sehr unkomplizierten Handling der Emulatoren unter Windows Phone 7.x kann es nun nötig werden, sich ausführlicher mit den Konfigurationsoptionen von Hyper-V auseinanderzusetzen (z.B. MAC-Spoofing), oder im Extremfall gar den Netzwerk-Admin zu bemühen, um die Emulatoren ins Unternehmensnetzwerk zu integrieren und ggfs. in Firewalls u.ä. freizuschalten – und das für jede Ausprägung der verfügbaren Emulatoren einzeln.