Fiddler ist das Standardwerkzeug zur Untersuchung von Web-Traffic. Er hängt sich als Proxy zwischen den eigenen PC und das Internet und erlaubt die detailierte Analyse ein- und ausgehenden HTTP(S) Verkehrs.
Möchte man jedoch die binär kodierten Nachrichten einsehen, die ein Silverlight Client mit einem WCF-Service austauscht, so wird es problematisch, weil Fiddler dieses Protokoll von Haus aus nicht beherrscht.
Microsoft bietet jedoch eine Erweiterung für Fiddler an, die diese Lücke schließt. Allerdings findet sich auch in der sehr flexibel erweiterbaren WCF eine Stelle, an der sich die Untersuchung von Nachrichten einbinden lässt. Dazu folgende Diskussion aus dem SDX Portal:
WCF Binary-encoded Message Inspector for Fiddler
Bislang habe ich beim Gespann Silverlight/Fiddler immer auf text encoding umgestellt um zu sehen, was über die Leitung geht (mit dem entsprechenden Aufwand).
Jetzt bin ich zufällig drüber gestolpert, dass man Fiddler beibringen kann, das binary encoding selbst zu decoden: http://code.msdn.microsoft.com/wcfbinaryinspector
Komentar 1:
Zwar nicht viel einfacher und mit etwas Aufwand: Hier beim Kunden wird für das Erstellen der WCF-Proxies eine Factory genutzt. Diese erstellt zu Laufzeit um den Proxy herum einen oder mehre weitere Proxies (Kaskade von Wrappern). Aktuell gibt es Proxies für Logging, Fehlerhandling usw. Wie passt da Ganze hier rein? ich habe mir mit 20 Zeilen Code einen Proxy geschrieben, der Request und Response in eine Datei legt. Dabei ist das Binding vollkommen egal, da dies vor dem eigentlichen WCF-Aufruf passiert. Für "Wie habt ihr uns aufgerufen und was habt ihr reingeschickt" ist das eine große Hilfe. Vor allem später in Produktion kann das Ganze mit einer Einstellung eingeschaltet werden. (unser Service greift auf 5 andere zu). Worauf ich hinaus will: Fiddler ist nett, habe ich auch auf meiner Kiste, aber so wie man sich Gedanken zu Logging und Tracing macht sollte man hier auch etwas Hirnschmalz reinstecken.
Komentar 2:
WCF bietet auch Infrastruktur für die Untersuchung ein- und ausgehender Nachrichten an
http://msdn.microsoft.com/en-us/library/system.servicemodel.dispatcher.iclientmessageinspector.aspx
Komentar 3:
Gefällt mir. Einziges Manko: man kann Request und Response nicht einander zuordnen. Also wenn ich einen Proxy habe und 3 Nachrichten drüber schicke (multithreaded, async, …) weiß ich nicht mehr wer zu wem gehört. Ich wollte eben im Dateinamen immer gleich sehen können welche Response zu welchem Request gehört.
Komentar 4:
Das kriegst du quasi geschenkt mit dazu.
BeforeSendRequest gibt einen correlationState vom Typ Object zurück. Dort kannst du hineinpacken was du möchtest. Standard ist die Verwendung einer eindeutigen Guid.
Und AfterReceiveReply bekommt vom Framework diesen correlationState gefüttert. Et voilá, du hast deine Zuordnung.