*Words of Wisdom From The Elder

TechEd 2010 was in New Orleans last week and I had the pleasure of doing a full day pre-conf session at TechEd.  Pre-confs are longer sessions where attendees can get into more details.  This year I did “.NET From Scratch” which was a one day session to introduce developers to the .NET platform. 

This seminar is for anyone who is starting at ground zero with .NET and wants a deep dive into the platform starting from scratch. It is designed for developers experienced in at least one other language, and starts with the basics of . NET and covers Microsoft Visual Studio, writing code in C#, and how to build applications in various technologies of the platform such as Windows, Web, Microsoft Silverlight, and Windows Mobile. If you are new to writing applications on Microsoft .NET, what better way to start your Tech·Ed experience?

As promised to the attendees, the slide decks and demos can be downloaded from the following URL:

http://keithelder.net/presentations/NETFromScratch/NETFromScratch.zip

Remember when learning a new platform as large as .NET the main thing to focus on are your immediate needs.  That may be a language and a framework and possibly web programming.  It is impossible to learn or know everything about a platform as large as .NET but knowing what is possible is half of the battle.  As engineers if we know it is possible it is just a matter of research to figure out how to make it happen. 

A big thank you to those that attended the session and I am truly sorry about how cold it was in the room.  If I’d known in advance I’d brought some firewood and blankets.  Enjoy.

A month or so ago I had the pleasure of being a guest on Geek Speak and the show is finally up on Channel9!  I showed how to deploy a complex WCF service from scratch that supported multiple bindings including:

• basicHttpBinding
• wsHttpBinding
• netTcpBinding
• netMsmqBinding

There isn’t a lot of information on how to setup this type of WCF service in IIS/WAS especially when it comes to setting up the queues.  After everything is deployed within IIS and WAS, I run some benchmarks to show the different speeds between the different bindings as well as against ASMX.  Which one do you think will win?

You can listen in to the show here:

http://channel9.msdn.com/shows/geekSpeak/geekSpeak-Recording-WCF-Deployment-Strategies-with-Keith-Elder/

You can download the solution I used here:

Here’s the problem.  When hosting WCF services using the NetMsmqBinding in IIS7/WAS (Windows Activation Service) the application times out after 20 minutes.  While this isn’t the problem and is the default behavior in IIS it leads to the problem.  When the application is timed out, if a new message arrives in the queue, the WCF service remains idle.  In other words messages will just pile up in the queue (not good!). 

After contacting support about this issue I finally got back some information on how to address this issue so I’m posting it in case someone else runs into this issue.  Here is what you should do if you run into this problem.

1. Ensure that the queue is named as virtual directory/serviceName.svc.  So if your application is at http://localhost/myTest/myTest.svc, the queue name should be myTest/myTest.svc.  We also should ensure that the WCF endpoint address reflects this queue name
2. Both the IIS worker process (App Pool) and the Net.Msmq Listener service should use the same account, this account must also have Peek and Receive rights on the queue (but it’s better to just give it full control).  You can verify the account used by your web service by checking the account used by w3wp.exe in task manager
3. Ensure that the Net.Msmq listener is running using an unrestricted token, the following command should work “sc sidtype netmsmqactivator unrestricted”
4. Add a DWORD called “AllowNonauthenticatedRpc” to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters\security, and set it to 1

Hope this helps someone, and if I find any other information, I’ll keep this updated.

A reader of this blog sent me an email asking the following question:

“I have an XSD that I am required to use to export my company’s data. How can I use that XSD and return data to them in a web method? I should be able to return a data set with the information formatted the way the XSD defines but I have no idea how to do that. Any ideas would save me a ton of time and grief!”

Turns out this is a really good question, and I think one a lot of developers struggle with primarily because the majority of developers are scared of XSD schemas.  Hopefully I can change that.  An XML Schema is really simple and it is your friend. 

What is an XSD or Xml Schema Definition?

An XML Schema describes the structure of an XML document.

That’s it, see, it isn’t that hard after all!

As a developer think of an XSD the same way you would when creating business rules to validate objects before storing them into a database.  Some items in objects cannot be null, some can.  Some need to have their data formatted (email address for example) and others need to not exceed certain lengths, etc. 

When dealing with an XML document, we need to apply the same type of rules and this is where the XSD comes in.  Once we have an XSD to describe an XML document we can guarantee any XML data we receive conforms to these rules.

Ok, enough intro, let’s get coding.

The Schema

In the case of the reader’s question, an XSD schema already existed.  To save time, I’ve taken then general idea of the schema I was sent and slimmed it down for simplicity sakes.  The schema represents an XML document that will contain job listings. Here is a view of the schema from the schema explorer in Visual Studio as well as the schema itself (again slimmed down).

   1: <xsd:schema

   2:   xmlns:xsd="http://www.w3.org/2001/XMLSchema"

   3:   targetNamespace="http://keithelder.net/Jobs"

   4:   xmlns:xs="http://keithelder.net/Jobs">

   5:  

   6:   <xsd:complexType name="JobListing">

   7:     <xsd:sequence>

   8:       <xsd:element maxOccurs="unbounded" minOccurs="1" name="job" type="xs:Job" />

   9:     </xsd:sequence>

  10:   </xsd:complexType>

  11:  

  12:   <xsd:complexType name="Job">

  13:     <xsd:sequence>

  14:       <xsd:element maxOccurs="1" minOccurs="1" name="Title"  type="xsd:string"></xsd:element>

  15:       <xsd:element maxOccurs="1" minOccurs="1" name="Description" type="xsd:string"></xsd:element>

  16:       <xsd:element maxOccurs="1" minOccurs="1" name="Location" type="xs:Address"></xsd:element>

  17:       <xsd:element minOccurs="0" maxOccurs="1" name="PostingDate" type="xsd:date"></xsd:element>

  18:       <xsd:element minOccurs="0" maxOccurs="1" name="CloseDate" type="xsd:date"></xsd:element>

  19:       <xsd:element minOccurs="0" maxOccurs="1" name="Benefits" type="xsd:string"></xsd:element>

  20:       <xsd:element maxOccurs="1" minOccurs="1" name="Salary"  type="xsd:string"></xsd:element>

  21:       <xsd:element maxOccurs="1" minOccurs="0" name="JobType" type="xs:JobType"></xsd:element>

  22:       <xsd:element minOccurs="0" maxOccurs="1" name="Function" type="xs:JobFunction"></xsd:element>

  23:       <xsd:element minOccurs="0" maxOccurs="1" name="Category" type="xs:JobCategory"></xsd:element>

  24:     </xsd:sequence>

  25:   </xsd:complexType>

  26:  

  27:   <xsd:simpleType name="JobType">

  28:     <xsd:restriction base="xsd:string">

  29:       <xsd:enumeration value="full-time"></xsd:enumeration>

  30:       <xsd:enumeration value="part-time"></xsd:enumeration>

  31:       <xsd:enumeration value="contractor"></xsd:enumeration>

  32:     </xsd:restriction>

  33:   </xsd:simpleType>

  34:  

  35:   <xsd:complexType name="Address">

  36:     <xsd:sequence>

  37:       <xsd:element minOccurs="0" maxOccurs="1" name="Street" type="xsd:string"></xsd:element>

  38:       <xsd:element minOccurs="0" maxOccurs="1" name="City" type="xsd:string">   </xsd:element>

  39:       <xsd:element minOccurs="0" maxOccurs="1" name="Country" type="xsd:string"></xsd:element>

  40:     </xsd:sequence>

  41:   </xsd:complexType>

  42:  

  43:   <xsd:simpleType name="JobCategory">

  44:     <xsd:restriction base="xsd:string">

  45:       <xsd:enumeration value="Automotive"/>

  46:       <xsd:enumeration value="Banking"/>

  47:       <xsd:enumeration value="Construction"/>

  48:       <xsd:enumeration value="Internet"/>

  49:       <xsd:enumeration value="Retail"/>

  50:       <xsd:enumeration value="Services"/>

  51:     </xsd:restriction>

  52:   </xsd:simpleType>

  53:  

  54:   <xsd:simpleType name="JobFunction">

  55:     <xsd:restriction base="xsd:string">

  56:       <xsd:enumeration value="Chief Peanut Butter Spreader"/>

  57:       <xsd:enumeration value="I ran the whole ship"/>

  58:       <xsd:enumeration value="Other"/>

  59:     </xsd:restriction>

  60:   </xsd:simpleType>

  61: </xsd:schema>

Once we have a schema defined like this we can generate code to be used for a service.  We have a tool at our disposal that is available within the Visual Studio Command Prompt called XSD.exe.  This executable does a lot of things but one thing it can do is generate code from an XML Schema Definition. 

When generating from the XSD file I was sent there was a problem with it.  Here is the walk through of that story so you can follow along. 

When I first tried this on the reader’s original XSD I got an error:

Warning: cannot generate classes because no top-level elements with complex type were found.

What does this mean?  Well, look at the screen shot of the XML Schema Explorer above.  Do you see the <> green icons?  Well those represent an XML Element.  An element is a fancy name for an XML tag like:  <Cows>Bramar</Cows> 

Let me roll this up and take another screen shot so you can start to see the problem (i have to hit my magic number of 12 screen shots anyway 🙂 ).

See the problem?  There isn’t an element in this schema (no green <> thingy).  What this means is we have a schema which just lists complex types of elements and enumerations.  There isn’t any “xml” in this schema.  The fix is simple though.  Add an element to the schema. 

   1: <xsd:element name="JobListing" type="xs:Job" />

Now we have a green thingy icon which means this XSD contains at least one element.  Basically think of the JobListing element as the root element.

Now that we have an element we can generate a C# class file from this XSD:

The code generated is about 350 lines so I’m not going to include it in the article.  There are some nice things happening for us when the C# classes are generated using xsd.exe. For starters the enumerations in the XSD are turned into C# enumerations.  The classes are marked serializable and they have the appropriate XML attributes on the properties to serialize these objects into XML.  This is a good thing since it means we didn’t have to create it.  Code generation is your friend.  Now that we have C# objects we can serialize these to XML easily. 

The Service

The first thing we need to do is create the WCF service.  For this example I chose to create a WCF Service Application in Visual Studio 2008.  After the project is initialized, the first thing we need to do is define the contract for the service.  In other words, what is coming in and going back out.  Since we have generated our code using the XSD utility we are going to use the XmlSerializer with our service.  The reason is this will make sure our XML formatted the way we intended.  While we are at it, I’ve made the service a RESTful type of service.  Here is the contract.

   1: [ServiceContract]

   2: public interface IJobService

   3: {

   4:  

   5:     [OperationContract]

   6:     [XmlSerializerFormat]

   7:     [System.ServiceModel.Web.WebGet(UriTemplate="/jobs/{type}", RequestFormat=WebMessageFormat.Xml)]

   8:     List<Job> GetJobListings(string type);

   9: }

The contract above has one method GetJobListings().  This method has two additional attributes.  One, the attribute to mark the method to serialize using the XmlSerializer and two the attribute to turn the method into a RESTful service.  In other words our service can be accessed like this:

http://localhost/service.svc/jobs/full-time

Now that the contract is setup, we just need a class to implement this contract on.  Here’s a quick and dirty implementation.

   1: public class Service1 : IJobService

   2: {

   3:  

   4:     #region IJobService Members

   5:  

   6:     public List<Job> GetJobListings(string type)

   7:     {

   8:         return GetJobs();

   9:     }

  10:  

  11:     private static List<Job> GetJobs()

  12:     {

  13:         var jobs = new List<Job>();

  14:         jobs.Add(new Job { JobType= JobType.parttime, Category = JobCategory.Banking, Benefits= "You are on your own.", Description="I did something" });

  15:         jobs.Add(new Job { JobType= JobType.fulltime, Category = JobCategory.Banking, Benefits= "You get something." });

  16:         jobs.Add(new Job { JobType= JobType.contractor, Category = JobCategory.Banking, Benefits= "Times are tuff, deal with it." });

  17:         jobs.Add(new Job { JobType= JobType.fulltime, Category = JobCategory.Banking, Benefits= "How does $700 billion sound?" });

  18:         return jobs;

  19:     }

  20:     #endregion

  21: }

Now all we have left is to get this working is to configure WCF to support our RESTful implementation.  In order to do this we are going to use the webHttpBinding.  Here is the WCF configuration to implement our RESTful service.

   1: <system.serviceModel>

   2:   <bindings>

   3:     <webHttpBinding>

   4:       <binding name="rest" />

   5:     </webHttpBinding>

   6:   </bindings>

   7:   <services>

   8:     <service behaviorConfiguration="WcfService1.Service1Behavior"

   9:      name="WcfService1.Service1">

  10:       <endpoint address="mex" binding="mexHttpBinding" name="wsdl"

  11:        contract="IMetadataExchange" />

  12:       <endpoint address="" behaviorConfiguration="NewBehavior" binding="webHttpBinding"

  13:        bindingConfiguration="" name="web" contract="WcfService1.IJobService" />

  14:     </service>

  15:   </services>

  16:   <behaviors>

  17:     <endpointBehaviors>

  18:       <behavior name="NewBehavior">

  19:         <webHttp />

  20:       </behavior>

  21:     </endpointBehaviors>

  22:     <serviceBehaviors>

  23:       <behavior name="WcfService1.Service1Behavior">

  24:         <serviceMetadata httpGetEnabled="true" />

  25:         <serviceDebug includeExceptionDetailInFaults="false" />

  26:       </behavior>

  27:     </serviceBehaviors>

  28:   </behaviors>

  29: </system.serviceModel>

That’s it, we are all setup.  Now all we have to do is launch the service and browse to the URL we outlined earlier to get our results.

This may seem like a lot of steps but it really isn’t.  I encourage you to take this example and play with it.  You can download the solution below.

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.