*Words of Wisdom From The Elder

I have a love hate relationship with Windows Communication Foundation.  I love it because the concepts of building a service are so simple.  I love the fact that I can expose the same service three different ways supporting different interoperability points within the business.  I also hate it because a there are so many ways to configure the service it can get daunting at times.  Configuration isn’t as bad as the built-in lack of ability to view messages.  WCF doesn’t provide a sample message page describing the SOAP messages for a request and response like the old ASMX services.  While this may not seem like a big deal there are systems I am having to interop with that can’t simply point to a WSDL and generate a proxy client from it (yes there still are some out there) and it is a problem.

The Problem

WCF offers a lot of binding options but when interopping with non .Net clients the basicHttpBinding is the obvious choice because it is the simplest.  If you can’t get that to work, good luck on the other ones.   Here is the quote from the MSDN pages about basicHttpBinding.

Represents a binding that a Windows Communication Foundation (WCF) service can use to configure and expose endpoints that are able to communicate with ASMX-based Web services and clients and other services that conform to the WS-I Basic Profile 1.1.

Changing bindings is really easy in WCF.  In VS2008, right click the config file in the project and select “Edit the WCF Configuration”.   The Microsoft Service Configuration Editor will then appear.  In the Services folder select the endpoint you want to change and in the binding section select the one you want.  This is the easy part.  The hard part is showing someone the message tied to the binding the service expects if they cannot generate a proxy within their language or platform from a WSDL.  In old ASMX services if the URL of the service was visited it would generate some nice pages for us automagically like this:

ASMX services display methods in service 

ASMX services when running locally could be easily tested with a prebuilt form

ASMX services provided a sample request and response XML message 

To the contrary WCF only provides .Net client info

Yeah it is real useful isn’t it?

The Quick Fix

Why this is the case I have no good explanation.  One would at least think if the service was configured with the basicHttpBinding it would offer close to the same features of old.  Not the case though.  There is a big difference in the two obviously.  My first thought was to write a pluggin or some code that would provide the same functionality the old ASMX services do but I realized I had enough side projects to work on and I didn’t have the time.  Thus I was looking for a quick alternative to the problem.

The very first thing I did was open the Microsoft Service Configuration Editor and enable Message Logging in the Diagnostics folder.

With this enabled messages are written to the client or server.  It is a nice built-in feature that takes a lot more work with ASMX services.  With message logging enabled I ran my test service which added two numbers and then opened the message log using the SvcTraceViewer.exe.  SvcTraceViewer is part of the Windows SDK and does not ship with Visual Studio by the way.  Here are the messages generated in the log and viewed via the trace viewer.

This almost gave me the result I wanted.  Notice that it includes a lot of extra nodes and information.  The only nodes we care about start and end with <s:Envelope />.  This is our actual SOAP message.  If the trace option is enabled in WCF via diagnostics even more information is shown within this message.  I wanted to know the *exact* message that was going over the wire and back and I wanted to be able to look at it as I wrote my service or debugged it not having to launch a new tool.  Here is what I came up with.

The Programmatic Fix

WCF has tons of hooks and hooks mean extensibility.  My goal was simple.  I wanted to capture the request before it left my client and then capture the response message when it was received.  At first I thought this was going to be hard.  Then I stumbled upon an interface called IClientMessageInspector and my troubles were then over.

The first thing I did was create a class called MessageViewerInspector which implemented two interfaces.  The IClientMessageInspector and IEndPointBehavior.  Then I added two properties to my object which contained the request and response messages.  After that I implemented both interfaces with the object.  The IEndPointBehavior interface has four methods that need implementing but I only needed to use one which was ApplyClientBehavior.  In this method I added my MessageViewerInspector to the clientRuntime.   The IClientMessageInspector has two methods that need to be implemented which are the before and after.  This is where we get to see the messages before they leave the client and as soon as they come back.  Here is the complete object that will allow us to view our messages in WCF.

    /// <summary>
    /// Provides a custom behavior that allows a client to capture messages and log
    /// them or assist in debugging messages.
    /// </summary>
    public class MessageViewerInspector : IEndpointBehavior, IClientMessageInspector
    {
        
        #region Properties
        public string RequestMessage { get; set; }
        public string ResponseMessage { get; set; }
        #endregion

        #region IEndpointBehavior Members
        public void AddBindingParameters(ServiceEndpoint endpoint, System.ServiceModel.Channels.BindingParameterCollection bindingParameters)
        {

        }

        public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)
        {
            // adds our inspector to the runtime
            clientRuntime.MessageInspectors.Add(this);
        }

        public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)
        {

        }

        public void Validate(ServiceEndpoint endpoint)
        {

        }
        #endregion

        #region IClientMessageInspector Members
        void IClientMessageInspector.AfterReceiveReply(ref System.ServiceModel.Channels.Message reply, object correlationState)
        {
            this.ResponseMessage = reply.ToString();
        }

        object IClientMessageInspector.BeforeSendRequest(ref System.ServiceModel.Channels.Message request, IClientChannel channel)
        {
            this.RequestMessage = request.ToString();
            return null;
        }
        #endregion
    }

All that was left was to add this custom inspector to the proxy as an endpoint behavior and we can see our messages coming and going.

Here is the code I added to my sample console application to test.

    class Program
    {
        static void Main(string[] args)
        {
            MessageViewerInspector inspector = new MessageViewerInspector();

            ServiceReference1.Service1Client proxy = new ConsoleApplication1.ServiceReference1.Service1Client();

            proxy.Endpoint.Behaviors.Add(inspector);
            proxy.AddTwoNumbers(12332, 12323);
            proxy.Close();

            Console.WriteLine("Request message:");
            Console.WriteLine(inspector.RequestMessage);
            Console.WriteLine(String.Empty);
            Console.WriteLine("Response message:");
            Console.WriteLine(inspector.ResponseMessage);
            Console.ReadLine();
        }
    }

As you can see above I created an instance of my new inspector and then added it to my proxy class.  After my request ran I simply printed the messages to the console as seen here.

The really nice thing with this approach that I liked is I now have the ability to view the request and response objects by simply placing a break point in either the after or before methods in the inspector class.  For example, here is a QuickWatch of the request object:

Now that the basic plumbing is in place we can do all sorts of things.  For example if an exception is thrown we could now log the specific message that was requested to cause our client to throw an exception.  Of course this also solves my original problem of being able to grab the specific messages sent and received and works with all bindings supported.  I hope this helps.