Seit einiger Weile hatte ich keine Zeit mehr hier Texte zu verfassen, doch da ich gerade ein wenig Verschnaufpause habe und sich einiges getan hat, dachte ich, ich könnte mal eine kurze Zusammenfassung abliefern:

Die Sache, die die meiste meiner Zeit auffraß in letzter Zeit war die Microsoft Prüfung 70-536: "Microsoft .NET Framework - Application Development Foundation". Nachdem ich bereits meine ganze Zeit in das Lernen für den ersten Versuch investiert hatte, musste ich mangels genügend Punkten einen zweiten Anlauf auf mich nehmen, den ich dann aber bestanden habe.

Natürlich bedeutete das Bestehen der Prüfung nicht, dass ich mehr Zeit hatte, denn die angestauten Aufgaben wollten natürlich abgearbeitet werden. Einige der privaten Projekte waren folgende:

Pixelkämpferin - alias Jessika Wollstein

Eine gute Freundin von mir, die ihre Künste als Grafikerin anpreisen möchte. An dieser Seite habe ich gerne gebastelt, weil ich ein wenig Spielereien ausprobieren konnte. Unter anderen eine volle Konfigurierbarkeit mit automatischem einlesen der Icons für alle Bereiche und eine nette Idee mit einem diagonalen Menü, bei der mir aber keine andere Idee kam als eine Image-Map zu verwenden, an die ich dann MouseOver Effekte gebunden habe.

Spielefinder.Net

Auf einer abendlichen Feier unterhielt ich mich mit dem Bruder meiner Freundin und ich fragte ihn, was man denn noch für kleine Tools basteln könnte, die es im Web nicht gibt. Irgendwann im Gesprächsverlauf über die verschiedensten Ideen, brachte er mich darauf, dass es zwar viele Spieledatenbanken gibt, keine davon aber erlaubte nach der eigenen Hardware zu suchen. Darum brachte ich vor knapp einer Woche eine Webseite online, die in der Lage ist gespeicherte Spieldaten in einer eigenen Datenbank nach der gewählten Hardware zu durchsuchen. Außerdem steht die Möglichkeit bereit über Slider (übrigens aus dem ASP.Net Ajax Toolkit stammend) eine Toleranz zu definiere, falls man sich gerne seinen Rechner aufrüsten würde, damit das Spiel bei einem läuft.

Codeplex - DownloadCounter

Und zu guter letzt: Ich habe heute auf Codeplex ein neues Projekt eingestellt namens "DownloadCounter". Momentan besteht es nur aus einer ganz einfach gestrickten Assembly und einem Demo-Projekt. Ich kam darauf, als mich der Freund meiner Schwester bat für ihn ein paar Dateien zum Download anzubieten, denn ich wollte ihm gerne die Möglichkeit bieten die Downloads der Musikstücke (er ist ein kleiner Hip-Hopper) nachzuhalten, um seinen Erfolg messen zu können. Und da ich bereits öfters Download-Counter geschrieben habe, dachte ich mir - ich könnte doch mal unter .Net einen bauen, den man wiederverwenden könnte - und damit das Projekt sich stetig verbessern kann, hoffe ich nun darauf, dass einige User sich das Projekt anschauen und ggf. mit Verbesserungswünschen an mich herantreten.

Nach einiger Zeit, habe ich mal wieder das SecurityToken-Projekt ausgegraben, um das in einem aktuellen Projekt zu verwenden. Als ich das Projekt aber anstieß und mich einloggte, erhielt ich einige Fehlermeldungen. Ich wusste nicht wo diese herkamen und ging deshalb den Code Step-By-Step im Debugger durch. Faszinierenderweise trat der Fehler nicht mehr auf und alles funktionierte anständig. Darum lud ich die Seite erneut und wieder schien alles problemlos zu laufen. Deshalb ging ich zuerst einmal von einem Cache-Problem aus und vergaß das Problem.

Einige Zeit später hatte ich meine Cookies gelöscht und wollte mir ein neues Token ausstellen - doch wieder erhielt ich einige Fehlermeldungen - doch wiederum verschwand der Fehler beim durchsteppen.

Daraufhin beschloss ich über mehrere Stellen im Code Breakpoints zu verteilen und sprang wesentlich schneller von einem zum nächsten, um die Stelle des Fehlers besser eingrenzen zu können. Als ich dann an der entsprechenden Stelle ankam, fand ich folgende Fehlermeldung vor:

"Das SamlToken ist zeitlich nicht gültig. Die aktuelle Zeit "14.05.2008 11:29:21" liegt außerhalb der effektiven Zeit "14.05.2008 11:29:59" und der Ablaufzeit "14.06.2008 11:29:59" des Tokens.

Was war passiert? Zuerst dachte ich, ich hätte versehentlich ein Problem in der Datumsberechnung, bis mir auffiel, dass das Token erst einige Sekunden NACH dem Ausstellen gültig wurde. Doch warum? War das eine eingebaute Funktion?

Nach kurzer Suche nach der Fehlermeldung fand ich einen Beitrag im Internet, der das selbe Problem hatte. Er hatte sich aber die Frage schon selbst beantwortet mit: "Ich stelle dann mal die Zeit meines Servers um" ... richtig ... der Dev-Server und mein PC hatten einen Zeitunterschied von ca. 30 Sekunden - deshalb war das Token NOCH nicht gültig, als es bei mir ankam - und deshalb funktionierte das durchsteppen immer, da dies die benötigte Zeit zum gültig werden überschritt, bis ich die entsprechende Stelle erreicht hatte.

Als ich neulich an einem privaten Projekt arbeitet, in welchem ich unter anderem Dateien vergleichen musste, stieß ich auf die integrierte "Diff"-Methode von SVN. Um den Vergleich durchzuführen, kann man SVN nach folgendem Schema aufrufen:

svn diff -r ALTE_REVISION:NEUE_REVISION DATEI

und schon erhält man eine Ausgabe der Unterschiede im diff-Format.

Um SVN aufzurufen, wollte ich in einer ASP.Net Klasse den Prozess im Hintergrund starten und einfach die Rückgabe abfangen. Leider hatte ich dabei ein kleines Problem. Der Output schien immer leer zu sein.

Als ich mich dann irgendwann nochmal daran versuchte, erhielt ich plötzlich den gewünschten Output. Direkt als ich nach Hause kam, wollte ich diesen Aufruf dann einbauen, doch wiederum schwieg die Rückgabe. Darum überlegte ich mir, wo wohl der Unterschied sein konnte. Zuerst vermutete ich, dass Vista den Output unterdrücken würde, da auf meinem Arbeitsrechner XP läuft, während mein Rechner zu Hause Vista hat. - Die Idee stellte sich aber als falsch heraus, als ich das Programm des Arbeitsrechners auf meinem Heim-PC ausführte... doch da kam ich drauf: Der Unterschied lieg im Anwendungstyp: Während ich das Projekt selbst als Webanwendung aufgesetzt habe, hatte ich das Testprojekt auf dem Arbeitsrechner als Konsolenanwendung erstellt.

Mein Code sah folgendermaßen aus:

ProcessStartInfo ps = new ProcessStartInfo("svn", "diff -r 4:6 file:///MEINE_LOKALE_DATEI");
ps.UseShellExecute = false;
ps.RedirectStandardOutput = true;

Process p = new Process();
p.StartInfo = ps;
p.Start();
p.WaitForExit();

string output = p.StandardOutput.ReadToEnd();

Der String "output" war hier bei der Webanwendung stehts leer (nicht null), während die Konsolenanwendung den richtigen Output zeigte:

Konsole:

Webanwendung:

Das Problem musste ich natürlich lösen, denn ich wollte mein Projekt nicht zu einer Desktop-Anwendung machen. Darum probierte ich ein wenig rum. Zuerst vermutete ich natürlich, dass es Probleme mit dem TrustLevel der Anwendung gab und dass Webanwendungen wesentlich restriktiver behandelt werden würden, aber jegliche Änderungen an den Sicherheitseinstellungen brachten keine Änderungen. Bis ich irgendwann im Internet einen Code-Schnipsel fand und das diesen 1:1 kopierte. Dieser funktionierte auch in der Webanwendung. Jedoch kaum hatte ich den Code wieder an meine Bedürfnisse angepasst und den "sinnlosen" Schrott rausgeworfen, klappte der Code wieder nicht. Darum bin ich dann Step-für-Step durchgegangen und habe dabei rausgefunden, woran es lag:

Die magische Standarteigenschaft der ProcessStartInfo heißt "RedirectStandardError". Kaum hatte ich die in meinem Projekt auf "true" gesetzt, klappte das einfangen:

HINWEIS:

Als ich diesen Blog-Eintrag hier schreiben wollte, hatte ich zuerst vor eine andere Anwendung als SVN zu verwenden und nahm "PING" stattdessen. Interessanterweise hatte ich plötzlich auch ohne "RedirectStandardError" eine Ausgabe in der Webanwendung:

Anscheinend ist es also auch ein wenig von der Art der Anwendung abhängig.

In letzter Zeit kam ich nicht oft dazu an dem Blog oder privaten Seiten zu arbeiten, da die Arbeit (glücklicherweise) viele Aufträge zu bieten hatte, die (leider) immer recht straff geplant waren.

Um kein größeres Thema hier aufzumachen, an dem ich dann länger schreiben würde und dass dann ggf. nicht so sauber abgehandelt werden würde, wie ich das gerne hätte, hab ich mir vorgenommen wenigstens die letzten Tools, die mir im Alltag über den Weg gelaufen sind hier vorzustellen:

VSO DivxToDVD

Die Tage wurde ich gebeten ein im Internet sehr umstrittenes Video auf DVD verfügbar zu machen, da einer meiner Bekannten keinen Computer hatte, um ins Internet zu gehen, geschweige denn sich das heruntergeladene DivX Video anzuschauen. Nach einigen Versuchen mit Software, die mehr schlecht als Recht war, führte mich Google auf die Seite von Softonic, wo ich den VSO DivxToDVD Converter 0.5.2.99 fand. Ein sehr cooles Tool, einfach gehalten und auch noch kostenlos:

Als ich mich nach einem Update beim Hersteller umschauen wollte, fand ich heraus, dass (zu meinem Bedauern) das nette kleine (und vor allem kostenlose ;-D) Tool mittlerweile kostenpflichtig geworden ist. Ich find gut, dass VSO sich dazu entschlossen hat, dieses Programm professionell zu vermarkten, denn ich finde, dass das Programm echt gut ist, aber natürlich habe ich keine Lust für eine einfache Konvertierung ab und an Geld auszugeben. Das Programm heißt mittlerweile ConvertXToDVD und kostet rund 40€.

(Hinweis: Softonic hat aber immer noch den Link zur alten, kostenfreien Version).

SDP Multimedia

Während der Suche nach einem Problem, fand ich letzte Woche zufällig einen Webcast, den ich mir gerne angeschaut hätte, der aber keinen direkten Downloadlink hatte. Er schien mir einige gute Infos zu enthalten, aber war einfach zu lang, um ihn mir mal kurz nebenbei anzuschauen. Darum versuchte ich ihn auf verschiedene Weisen runterzuladen, was allerdings nicht klappte, bis ich den Streamripper SDP Multimedia fand.

Er ist zwar ein wenig langsam im Download (oder vielleicht war das auch der Streaming-Server :-D), aber auf jeden Fall wiederum kostenlos.

Man braucht lediglich einen Stream über das MMS Protokoll angeben, und schon wandert das Video auf die Platte.

FileSystemWatcher

Nachdem wir bei uns auf der Arbeit schon seit längerer Zeit VisualCron verwenden, um unsere Dateibasierten-Cronjobs aufzusetzen, musste ich neulich feststellen, dass beim .Net Framework ebenfalls eine Hilfsklasse zu diesem Zweck vorhanden ist: System.IO.FileSystemWatcher.

Dieses Objekt erlaubt es das Dateisystem zu beobachten und auf bestimmte Änderungen zu reagieren. Dazu muss man lediglich das Objekt instanziieren, das Verzeichnis, welches es zu überwachen gilt nennen, (auf Wunsch eine Maske (z.B. nur .cs-Dateien) definieren und dem Objekt sagen, dass es die Überwachung starten soll:

System.IO.FileSystemWatcher fsWatcher = new System.IO.FileSystemWatcher();

fsWatcher.Path = @"C:\fsWatcherTest";
fsWatcher.Created += new System.IO.FileSystemEventHandler(FileCreated);
fsWatcher.WaitForChanged(System.IO.WatcherChangeTypes.Created);

Mit diesem Code würde der FileSystemWatcher auf das Erstellen von genau einer Datei warten und dann die Methode FileCreated aufrufen. Um auch Umbenennungen zu reagieren und zwar nicht nur einmal, sondern mehrfach, habe ich das Programm folgendermaßen erweitert:

class Program
{
    static void Main(string[] args)
    {
        System.IO.FileSystemWatcher fsWatcher = new System.IO.FileSystemWatcher();

        fsWatcher.Path = @"C:\fsWatcherTest";
        fsWatcher.Created += new System.IO.FileSystemEventHandler(FileCreated);
        fsWatcher.Renamed += new System.IO.RenamedEventHandler(FileRenamed);

        while (true)
        {
            fsWatcher.WaitForChanged(System.IO.WatcherChangeTypes.Created);
            fsWatcher.WaitForChanged(System.IO.WatcherChangeTypes.Renamed);
        }
    }

    static void FileCreated(object sender, System.IO.FileSystemEventArgs e)
    {
        Console.WriteLine(String.Format("File Created: {0}", e.FullPath));
    }

    static void FileRenamed(object sender, System.IO.RenamedEventArgs e)
    {
        Console.WriteLine("---");
        Console.WriteLine("File Renamed:");
        Console.WriteLine(String.Format("Old path: {0}", e.OldFullPath));
        Console.WriteLine(String.Format("Old name: {0}", e.OldName));
        Console.WriteLine(String.Format("New path: {0}", e.FullPath));
        Console.WriteLine(String.Format("New name: {0}", e.Name));
        Console.WriteLine("---");
    }
}

Folgende Schritte habe ich danach gemacht:

1.) Das Programm gestartet.

2.) Eine Textdatei in dem Ordner erstellt.

3.) Diese Textdatei umbenannt.

Dabei entstand folgende Ausgabe:

Interessant dabei: Wenn ich eine neue Datei unter Vista via Rechtsklick erstelle, dann erscheint die Datei in dem Verzeichnis und der Name (ohne Dateiendung) wird markiert, damit ich den Namen direkt ändern kann. Wie ich es gerade in diesem Satz beschrieben habe, wird die Datei wirklich zuerst erstellt und dann nachträglich geändert (was auch in der Anwendung oben zu sehen ist). Also passt auf, denn die Datei könnte nach dem Erstellen evtl. noch nicht den finalen Namen haben.

Heute morgen war es soweit. Fast wie an Weihnachten freute ich mich, als ich beim betreten der "Sitecore Xpress"-Seite nicht mehr den altbekannten Teaser "Coming to a server near you..." sah, sondern der Download direkt vor meiner Nase lag. Ich hab mich natürlich auch direkt eingeloggt, um es zu herunterzuladen. Knappe 250MB haben dann weniger als 10Minuten gebraucht, um sich auf meinem Desktop einzufinden ... der Lizenz-Code leider etwas länger ... den hatte ich erst gegen 16Uhr in Händen, aber das war das warten auch wert, denn ICH KANN ENDLICH UNTER VISTA DAMIT SPIELEN ...

Das kommerzielle Sitecore (neuerdings auch "Sitecore red" benannt), hat da bei mir noch ein paar Probleme mit dem IIS unter Vista gemacht, was aber in der nächsten Version auch behoben werden soll.

Schön ist auf jeden Fall, dass es wirklich ausreichte die Fehlermeldung am Anfang (über den nicht laufenden IIS) zu ignorieren und einfach drauflos zu installieren - und siehe da - nach einigen Minuten tauchte die vorkonfigurierte Standard-Seite in meinem Browserfenster bei mir auf:

Das hat mein Herz dann doch sehr erfreut.

Aber was ist Sitecore eigentlich? Sitecore ist ein hochentwickeltes CMS - und zwar das beste, dass ich bisher gesehen habe. Man fühlt sich quasi auf dem heimischen Desktop, wenn man direkt nach dem Login auf einer Seite wie folgender begrüßt wird:

(Und das ist ein Screenshot von der aktuellen Version) ... wundert euch übrigens nicht, wenn alle Funktionen beim ersten Mal etwas länger brauchen ... Das liegt schlichtweg daran, dass .Net die Sitecore-Libraries ja kompilieren muss.

Wie ihr auf dem Screenshot sehen kann, ist die Oberfläche einem Windows-Desktop nachempfunden ... und auch der so genannte "Content Editor" entspricht schon sehr dem Aussehen des Windows-Explorers. Als Windows-User dürfte man also kaum Probleme haben sich zurechtzufinden:

Wenn ihr also gerne mal ein CMS ausprobieren möchtet, dass normalerweise kostenpflichtig ist und in Enterprise Lösungen eingesetzt wird, dann ladet euch Sitecore Xpress auf jeden Fall einmal herunter, denn es ist kostenlos und soviel Spaß mit einem CMS werdet ihr selten haben ;-).

Links

Sitecore Webseite

Sitecore Xpress Webseite (DOWNLOAD)

Deutscher Sitecore Solution Partner "netzkern GmbH"

Da ich heute bereits zum zweiten Mal auf diesen Fehler traf (das letzte Mal liegt schon einige Wochen zurück), dachte ich mir, dass ich ihn mal hier verewige:

Wenn die Fehlermeldungen "Bad Key" oder "Invalid handle" in Zusammenhang mit einer "System.Security.Cryptography.CryptographicException" bei euch fallen, solltet ihr zuerst einmal die Schreibrechte der Private-Key-Datei testen und im zweiten Schritt dann überprüfen, ob euer Zertifikat überhaupt die benötigten Werte enthält.

Mein Problem: Ich versuchte ein X.509-Zertifikat zu verwenden, um ein Saml-Token zu signieren. Dummerweise traten gleich an zwei verschiedenen Stellen Fehler auf, die ein unüberlegter Catch-Block (im Zusammenspiel mit einem nicht funktionierenden Logger) so verschleierte, dass eine längere Suche von Nöten war.

Beide Fehler traten übrigens beim Serialisieren des Tokens auf.

Zwei Probleme und ihre Lösungen:

Problem 1 - "Invalid handle": Dieser Fehler trat auf, wenn das Script nicht auf die Private-Key-Datei des Zertifikats zugreifen konnte. Der Benutzer "NETWORK SERVICE" braucht hier zumindest Leserechte.

Wie finde ich die Private-Key-Datei? Dazu gibt es von Microsoft eine schöne Sammlung namens WSE "Web Service Enhancements"... die Version, die meiner Ansicht nach am neusten ist, ist Version 3.0, wenn ihr auch bei Google zuerst auf die 2.0er Version stoßen werdet.

Diese Sammlung beinhaltet ein Tool namens "WSE X.509 Certificate Tool", mit welchem man durch einfaches Auswählen von Dropdowns und Buttons alle Details zu einem bestimmten Zertifikat erfahren kann. Hier zum Beispiel die Ansicht des Testzertifikats, welches ich mir ausgestellt habe.

Am unteren Ende des Tools, findet man einen Button "View Private Key File Properties", welcher einen direkt in den Eigenschaften-Dialog der entsprechenden Datei führt. Die neueren Windows-Systeme enthalten dort einen Reiter "Sicherheit", mit dem man direkt der Datei den entsprechenden Benutzer (in unserem Fall "NETWORK SERVICE") zuweisen kann. Sobald die Datei für das Script zugänglich ist, verschwindet die "invalid handle"-Fehlermeldung.

Problem 2 - "Bad key": Wer lesen kann ist klar im Vorteil, denn auch hier liefert das Tool eine direkte Erklärung:

Sobald das eine Feld links (siehe Bild 1) durch drei Felder (siehe Bild 2) ersetzt wird, erscheint rechts in der Beschreibung der Text "Wenn der Subject Key Identifier nicht vorhanden ist, werden drei Felder angezeigt". Hätte ich hier beim zweiten Anlauf richtig gelesen, hätte mir das einige Mühe erspart, denn das Zertifikat, dass ich mir habe ausstellen lassen, verfügte schlichtweg nicht über den sog. "Subject Key Identifier", welcher nötigt ist, um das Saml-Token zu authentifizieren. Sobald man ein Zertifikat mit dem oben genannten SKI besitzt, wird ganz sicher auch die Fehlermeldung verschwinden.

Die WSE Tools findet man auf der Microsoft-Download-Seite.

Einen kleinen Tipp hätte ich noch zur Hand. Wenn ihr eure Software gegen Zertifikate testen wollt, dann könnt ihr euch Zertifikate mit allen möglichen Kombinationen an Rechten mit einem Tool von EldoS namens "Crypto4™ PKI" erstellen. Dieses Tool ist kostenpflichtig, erstellt aber auch in der 30-Tage Testversion wunderschöne Zertifikate ;-).

Nachdem mir vor einiger Zeit auf tutorials.de leider niemand helfen konnte bei dem Versuch ein- und ausgehende Nachrichten bei WCF mitzuloggen und zu untersuchen, dachte ich, dass ich hier einmal meine Erfahrung zur Verfügung stelle:

WCF bietet standardmäßig eine Konfiguration für das MessageLogging. Dieser ist Teil der sog. "Diagnostics"-Einstellungen und vollkommen ausreichend, wenn es wirklich nur um das Loggen an sich geht. Den entsprechenden Artikel dazu findet man im MSDN.

Leider lässt sich dieses Logging nicht so detailiert konfigurieren, wie ich das damals brauchte. Meine Aufgabe war es nämlich die eigentliche Message zu einem gesendeten Objekt zu speichern, um nachhalten zu können, ob der vorgeschaltete Wrapper anständig arbeitete.

Nach einiger Suche, fand ich den Ansatz der "Extensions". Und dieser funktioniert folgendermaßen.

Über die Konfiguration lässt sich einem Endpunkt ein Endpoint-Behavior zuweisen:

<endpoint address="ADDRESS" binding="basicHttpBinding" behaviorConfiguration="AttachClientInspector" contract="CONTRACT" />

Hierzu entsprechend muss natürlich auch ein Behavior namens "AttachClientInspector" vorhanden sein (den Namen könnt ihr euch natürlich selber aussuchen). Dieser sähe ungefähr so aus:

<endpointBehaviors>
  <behavior name="AttachClientInspector">
    <ClientInspector />
  </behavior>
</endpointBehaviors>

Falls ihr das Visual Studio 2005 verwendet, wundert euch nicht, dass der einzelne Tag "ClientInspector"-Tag markiert wird mit dem Text "...invalid child element". Das liegt schlichtweg daran, dass das VS2005 die eigentliche Extension nicht erkennt. Und hier kommen wir auch direkt zum nächsten Schritt, denn der Konfigurationsabschnitt "System.ServiceModel" erlaubt neben "Bindings" und "Behaviors" auch einen Abschnitt namens "Extensions". Hier könnt ihr eine sog. "BehaviorExtension" hinzufügen:

<behaviorExtensions>
  <add name="ClientInspector " type="CLASSNAME, ASSEMBLYNAME, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
</behaviorExtensions>

Der CLASSNAME muss natürlich auf eine bestimmte Klasse zeigen, welche für das Untersuchen der Nachricht geeignet ist. Damit diese Klasse hier akzeptiert wird, muss sie von "System.ServiceModel.Configuration.BehaviorExtensionElement" ableiten UND "System.ServiceModel.Description.IEndpointBehavior" implementieren. Von BehaviorExtensionElement muss man ableiten, damit die Klasse als Extension an das Behavior gebunden werden kann. Sie verlangt die Bereitstellung von BehaviorType, wobei man einfach via typeof die aktuelle Klasse angeben kann und die Methode CreateBehavior, bei der man nur eine Instanz der aktuellen Klasse zurückgeben muss:

public override Type BehaviorType
{
    get { return typeof(CLASSNAME); }
}

protected override object CreateBehavior()
{
    return new CLASSNAME();
}

IEndpointBehavior hingegen stellt die Methoden zur Verfügung, die schließlich während der Laufzeit aufgerufen werden, sobald die entsprechende Extension greift. Hierbei interessiert uns nur die Methode "ApplyClientBehavior". Diese besitzt einen Parameter "clientRuntime" vom gleichnamigen Typen. Hier lässt sich unser Inspector nun wie folgt einbauen:

clientRuntime.MessageInspectors.Add(new CUSTOMINSPECTOR());

So... damit hätten wir schonmal den Grundstein gelegt, damit der Inspector aufgerufen wird, sobald der entsprechende Endpunkt verwendet wird. Jetzt fehlt nur noch die eigentliche Implementation des Inspectors. Hierzu erstellt ihr eine Klasse mit dem Namen CUSTOMINSPECTOR (die groß geschriebenen Wörter sind natürlich nur Platzhalter, um die Relationen klar zu stellen) und leitet vom Typ "System.ServiceModel.Dispatcher.IClientMessageInspector" ab. Dieses Interface setzt euch zwei Methoden vor: AfterReceiveReply und BeforeSendRequest. Letztere erwartet einen Rückgabetypen vom Typ "object"... schreibt einfach "return null;" hinein, denn der Rückgabewert interessiert uns hier nicht.

Wenn ihr jetzt versucht zu kompilieren, dürfte er nicht meckern und müsste das Projekt anständig bauen. Was natürlich noch immer fehlt, ist die eigentliche Implementation der Inspectors. Hierfür besitzen beide Methoden einen Parameter vom Typ "System.ServiceModel.Channels.Message". Darin enthalten ist die entsprechende Nachricht.

Wenn ihr aber nun das erste Mal versuchen solltet auf die Nachricht zuzugreifen, dürftet ihr nach kurzem genervt sein, denn das Nachrichten-Objekt wird ungültig, sobald ihr zum ersten Mal darauf zugreift. Schön, nicht? ;-)

Aber auch dieses Problem ist recht einfach zu meistern, denn die Message-Objekte besitzen eine Methode "CreateBufferedCopy". Mit folgendem Aufruf könnt ihr euch dann eine "buffered Copy" des aktuellen Message-Objekts erstellen:

MessageBuffer bufferedMessage = request.CreateBufferedCopy(request.ToString().Length);

(Hierbei ist das Message-Objekt "request". Bei "AfterReceiveReply" nennt sich das Objekt hingegen "reply".)

Aus der "Buffered Copy" könnt ihr dann, nachdem ihr eure Analyse abgeschlossen habt, wieder ein MessageObjekt erzeugen:

request = bufferedMessage.CreateMessage();

(Wieder entsprechend "reply" natürlich bei der Reply-Methode. Das Objekt, das hier gefüllt wird, ist das selbe, wie im Parameter übergeben wurde.)

Das ist eigentlich alles, was man dazu wissen muss. Um zu Analysezwecken an den Inhalt zu kommen, hat man dann verschiedene Möglichkeiten:

1.) Aus der "bufferedMessage" kann man via "CreateNavigator" einen XPathNavigator generieren, mit dem man dann die Nachricht untersuchen kann. Außerdem kann man an jedem beliebigen Punkt des XPathNavigators auf die Eigenschaft "InnerXML" zugreifen, welche den Inhalt der untergeordneten Knoten als String bereitstellt.

2.) Man kann, wie vielleicht weiter oben schon bemerkt, aber auch direkt request.ToString() machen und erhält so den Inhalt der Nachricht.

Ich wünsche euch viel Erfolg damit und hoffe ich konnte euch helfen.