Archive for March, 2010

Logging .Net Socket Traffic

March 30, 2010

I was unsure what title to give this blog; it’s really about two things. Firstly it about tracing (or logging) network activity and secondly it’s a bit of a rant about logging that information to a file or the like.

I recently created an application built on WCF. One of the things I wanted to do was log the messages sent and received. After a quick search I realized that WCF used the standard .Net System.Diagnostics.Trace so you could capture trace from WCF by adding a few lines to your App.Config file. More recently I have been developing an app that uses a 3rd party library that uses the .Net equivalent of Sockets (rather than WCF). What I didn’t realize was that you could still trace the network traffic. Adding these few lines to my App.Config file did the trick.

<system.diagnostics>
  <trace autoflush="true" indentsize="4" />
  <sources>
    <source name="System.Net">
      <listeners>
        <add name="System.Net"/>
      </listeners>
    </source>
    <source name="System.Net.Sockets">
      <listeners>
        <add name="System.Net"/>
      </listeners>
    </source>
    <source name="System.Net.Cache">
      <listeners>
        <add name="System.Net"/>
      </listeners>
    </source>
  </sources>
  <sharedListeners>
    <add
      name="System.Net"
      type="System.Diagnostics.TextWriterTraceListener"
      initializeData="C:\Logs\WCF.log" />
  </sharedListeners>
  <switches>
    <add name="System.Net" value="Verbose" />
    <add name="System.Net.Sockets" value="Verbose" />
    <add name="System.Net.Cache" value="Verbose" />
  </switches>
</system.diagnostics>

[Just change "C:\Logs\WCF.log" to whatever you like.]

You can replace the ‘TextWriterTraceListener’ with ‘XmlWriterTraceListener’ and you should be able to use the Service Trace Viewer Tool (SvcTraceViewer.exe) to view the output; something I haven’t tried.

This brings me onto my second point; why are so many people wasting valuable time creating ‘log’ libraries. You only have to do a simple search of CodePlex to find more libraries than just about anything else; NLog, Clog, Live Labs, etc. My point is that .Net already has a good, simple interface in System.Diagnostics.Trace so why do people insist on creating something else. Why not simply provide additional TraceListeners that enhance the existing .Net Trace?

Technorati Tags: ,,

DataBinding tabular data to a FlowDocument

March 22, 2010
Technorati Tags:

I’ve come back to WPF development after an initial look at it.

One of the tasks I had was to provide a viewer for text event messages. There were a number of requirements over a basic viewer…

•    It needed to support ‘rich text’; like bold, italic and coloured text.
•    It needed to support Copy and Paste into Word.
•    Print (with preview) was required.
•    and it had to be searchable.

I looked initially at the RichTextBox control and while this did a lot of what I wanted it seemed as if the FlowDocument control did just about everything. The big problem I had was the lack of data binding. I solved part of that when I can across the BindableRun code here that allowed me to bind text to a Run element in a FlowDocument. The next problem was how to bind to a table of messages.

FlowDocuments can contain tabular data but as with the Run there was no way to databind. Until, that is, I found Vincent Van Den Berghe’s article in MSDN Mag (April, 2009, page 59). The article explains how he did it.

There was one piece of functionality that didn’t work. My test application worked fine if I populated the table before the document was rendered, but failed to detect changes and update itself. Specifically, I added some code that went off to the Google Translation Service to translate my messages into another language and the translated messages weren’t being rendered. I finally solved this by adding in a handler for the CollectionChanged event.

[One thing I find frustrating with WPF samples is the [over]use of static resources for data. In the real world your data will be coming from some source; DB, Object Class. Static resources often mask other issues; like not handling a change in a collection…rant over]

So, why not simply embed a UI table; like a ListBox or GridView into the FlowDocument? The answer is simple; you can’t search the data in embedded controls and if you copy the FlowDocument contents into Word, the UI elements don’t come across. This even applies to simple elements; like TextBlock.

Here’s the source code which also includes a Print Preview control.

You should be able to get the sample code here.