I recently ran into some issues with a third-party web service, and needed view the request xml being sent down the wire.  The options came down to using a sniffer to watch HTTP traffic sent from my application or implement a SoapExtension to intercept the different phases of the SOAP request.

My first approach was to use a traffic sniffing tool such as Fiddler.  Unfortunately, using Fiddler with SSL Secured Web Services is tricky at best.  The process involves a number of changes to Fiddler's configuration.  I decided to take another route, but if this is something you are interested in, there is a great in-depth article by Rick Strahl at WestWind Technologies on how to configure Fiddler for HTTP traffic monitoring.

After playing with Fiddler for a while, I decided to take a different approach and use the SoapExtension base class to create a custom extension to intercept request and response data streams.  Doing this allows me to do what ever I want with the data.  For this purpose, I simply logged the messages to xml files on my local machine, but I could also see using the extension to log xml data to a database.

The MSDN documentation on SoapExtensions shows a decent example, but the best example I found was an article on MSDN Magazine.  It includes sample code, and also shows how to use the extension on both the client and the server.  On the server you implement the extension using a custom attribute applied your Xml Service Method.  On the client, you can add your custom extension in your web.config or app.config section in system.web\soapExtensionTypes.

I was fishing through some old posts on Joel Spolsky's blog and came across a series he did titled Painless Functional Specs.  There are 4 parts to the series, but it is worth the read.  

I like to to think of spec writing as... THINK FIRST DEVELOPMENT, or TFD.  You heard it first here!

He has a great quote in the first post... "failing to write a spec is the single biggest unnecessary risk you take in a software project. It's as stupid as setting off to cross the Mojave desert with just the clothes on your back, hoping to "wing it."

This was a great blog series, and I am glad that I came across it.  Not having specs means that every person on the project is working on the assumption that they all have the same understanding in their heads about how a system should or should not operate.  But of course the reality of that happening is very unlikely.

Spec writing lays out out the project needs and requirements in a written document, which can be referenced in the future by all parties involved.

I do agree with Joel that specs are likely to be left out because "nobody reads them".  But he makes the point that specs often don't get read because they just are not written in a easy-to-read fashion.  He suggests writing specs in a conversational tone and adding humor.  Basically, it takes good writing skills, and not many people are good at or enjoy writing.

Part of the reason I write these blog posts is for the sheer practice of writing.  I want to be a good writer.  Maybe someday I'll be funny, too.

I've been trying to apply generics in my code more often. A common place for change is any code that uses the gets a typename of any kind. For example, typeof(MyType) or MyObj.GetType().  Just created a nifty method to make parsing Enums a little easier.

Let's start with our Enum definition

public enum ShoeTypes {
    Nike,
    Sketcher,
    DrMartins
}

In the past, I have always been able to parse a string into an Enum using the Enum.Parse() method...

    ShoeTypes _myShoe = (ShoeTypes)Enum.Parse(typeof(ShoeTypes), "DrMartins"));

That's a bit wordy. So, I created a custom enum parser method using generics. My new version ends up looking like this...

ShoeTypes _myShoe = ParseEnum("DrMartins");

And code for ParseEnum looks like this...

    private T ParseEnum(string value)
    {
        return (T)Enum.Parse(typeof(T), value);
    }

Ideally, you would put this method in a utility class where it could be used throughout your code base. This is just a simple example how the use of generics can improve the organization and readability of your code.

I am a bit frustrated at the moment.  I have a complicated xml schema (.xsd) and I need a practical way to code against that schema in C# .NET.  In the past, I have used tools like XSD.exe or it's Visual Studio add-in counterpart, XSDObjectGen.  These generate C# classes from the schema, which is nice, but I've come across several posts about the promise of Linq to Xsd and how you can program to the XSD in a LINQ fashion without generating class files.  Sounds pretty cool, but where do we start?

A Confusing Web Search

The LINQ to XSD Preview Alpha 0.2 Refresh...

There are some articles and posts out there that will mention the LINQ to XSD Preview Alpha 0.2 Refresh.  As of the date of this post, that link says the download was published on February 2, 2008.  Check the date of blogs/articles mentioning this download.  It seems many I have found were written in '07 or '08, and may be out of date.

Others will mention that the place to get LINQ to XSD is actually from CodePlex... LINQ to XSD on CodePlex, and this apparently does have a recent date (currently Sep 22, 2010).

Your initial attempt at the codeplex site might be to click the Download button on the home page, BUT DON'T!   This just has a few DLL's and a command line utility.  What you REALLY want is the Source Code Download.  There you will find a full package, complete with README.txt and a Docs folder!

More about LINQ to XSD on CodePlex

Having the source code on CodePlex means the project has moved to an open source model, which means Microsoft has lost interest in getting this project to a full release state.  Or, maybe they just figured if they open source it, they don't have to support it...?

The release to CodePlex was mentioned in this blog post on the Microsoft XML Team Blog.  There is talk on the web about the project being dead, but it looks like there is a talented developer named Sergey Shandar who has been making a lot of changes to the source.

Summary

Basically, I wrote this post to help prevent confusion in your hunt for Linq To XSD.  It comes down to... DO NOT download the old preview!  I don't even know why it is still available, but you are asking for trouble if you start there!  DO use the CodePlex site, but DON'T use the download from the download page!  Instead, download the source code and follow the instructions in the /trunk/README.txt file.

Future post... how to actually use LINQ to XSD!