Dave Jansen\’s Blog

Error when Behaviour Extension types are not fully qualified

Custom behaviour extensions are a great way to customise service behaviour such as implementing exception shielding as described here in Rory’s post  or message validation using the Microsoft Enterprise Library Validation Application block.

I recently implemented a custom WCF behaviour extension for shielding exceptions when I came across the following cryptic exception.

“An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.”

While the message was somewhat cryptic, it pointed me to the service behaviour were I realised I had specified the incorrect version on the type attribute.

Steps

1. Create new behaviour extension. My extension shielded and traced certain exceptions using the IErrorHandler.
2. Use SVC Configuration Editor to plug the extension in. It added the following configuration as expected.

3. Ran integration unit tests that passed.
4. The service build was integrated into TeamBuild which happen to automatically update my AssemblyInfo version files.
5. As soon as a TeamBuild kicked off and the assembly version changed, I received the cryptic error.
6. I realised I had an incorrect version configured in the web.config so I replaced the fully qualified type with:

7. Ran tests and failed.

After attempting to diagnose the issue using tools such as Fusion Log Viewer, I checked Google (which I should have done first) and came across several posts also identifying the issue – including a closed and unresolved issue on Microsoft Connect. This is the second time round I have been to Microsoft Connect regarding a bug and it does not look like they will resolve this anytime soon.

A Way Forward

At this stage since there is no fix, a tedious workaround will have to be to get TeamBuild to modify the web.config and update the version number of the behaviour extension when applying a new version – which in my case is for every CI build triggered by a code checkin.

Links

• Mitch Denny has a good blog post/rant on this here.
• Microsoft Connect issue was raised but it was interestingly closed.
• Keyvan also reports the problem here.

Handling Fault Contracts

Today I had an issue with catching Fault Contracts thrown from my WCF service. Every FaultException type raised by the service (excluding Communication Exceptions) were caught by the client as a FaultException instead of the expected FaultException<T>.

The issue was that I defined the FaultContractAttribute(type) on the operations in the Service Implementation class instead of on the Service Contract’s (Interface class) operations.

A service should always handle/shield exceptions and throw them as either a FaultException or a FaultException<T>. These types will not cause the channel to be faulted. I recommend defining Fault Contracts to convey information about the problem to client applications, and DO NOT provide the internal exception such as service stack traces. I’ll blog a post in the future on my recommendations service exception shielding patterns.

To catch Fault Contract types on the client, make sure that each Fault Contract type you require for that service operation, ensure that the FaultContractAttribute(Type) is specified.

Service code

Error Handler

The following code is implemented in the IErrorHandler class and is based on Rory’s post on Implementing IErrorHandler . In this example, all exceptions in my WCF service are changed to FaultException<ServiceFault>.

public void ProvideFault(Exception error,
                         MessageVersion version,
                         ref Message fault)
{
    // Return a 'ServiceFault' Fault Contract
    ServiceFault faultDetail = new ServiceFault("An error occured");

    // Construct FaultException with Fault Contract and FaultReason
    FaultException<ServiceFault> faultException = 
        new FaultException<ServiceFault>(faultDetail, 
        new FaultReason("FaultReasonText"));

    // Construct MessageFault to return.
    MessageFault messageFault = faultException.CreateMessageFault();

    fault = Message.CreateMessage(version, 
        messageFault, 
        faultException.Action);
}

Service Contract

Now this is where I went wrong. I did not decorate my service contract with the FaultContractAttribute. This attribute accepts a Type parameter which should be the type of the Fault Contract.

Service Fault Contract code

Here is a defined Fault Contract used by the service and client. Being a Data Contract, it could contain a collection of error messages e.g. a collection of validation error messages for a set of fields that were incorrectly set on the service operation.

using System;
using System.Runtime.Serialization;

namespace Wcf.Demo.ServiceContracts
{
    [DataContract]
    public class ServiceFault
    {
        public ServiceFault(String message)
        {
            Message = message;
        }

        [DataMember]
        public String Message
        {
            get;
            set;
        }
    }
}

Client code

The service calling code below shows several catch statements. When the service passes back a ServiceFault, it will be caught in: catch (FaultException<ServiceFault>. All other FaultException and FaultException<T> types will be handled by: catch (FaultException fault) block.

Unhandled service exceptions will be raised and caught in:  catch (CommunicationException cex) which will cause the WCF channel to fault, thus forcing the client to create a new channel.

try
{
    using (ChannelFactory<IDemoService> channel = 
        new ChannelFactory<IDemoService>("DemoService"))
    {
        IDemoService service = channel.CreateChannel();
        channel.Open();

        return service.GetPerson(42);
    }
}
catch (FaultException<ServiceFault> serviceFault)
{
    MessageBox.Show(serviceFault.Message);
}
catch (FaultException fault)
{
    MessageBox.Show("Unknown Service Fault");
}
catch (TimeoutException tex)
{
    MessageBox.Show("Service call timed out. Please retry.");
}
catch (CommunicationException cex)
{
    MessageBox.Show("Unknown Communications exception occured.");
}

Controlling the serialized order of WCF Data Contract Members

There are situations where you wish to specify the order of fields when they are serialized. I believe that a good designed service should not specify the ordering of fields nor should a service consuming application expect it..

In some applications, it is useful to know the order in which data from the various data members is sent or is expected to be received (such as the order in which data appears in the serialized XML). Sometimes it may be necessary to change this order…..

Recently, I started using ReSharper (now I’m hooked). I used it to reformat my code based on a style which alphabetically reordered all the properties in the data contracts. The changes were checked in, unit tested, integrated united tested and deployed to Test. The changes I made broke the client application as the application was relying on the serialised Xml to be in a certain order. In my opinion this is definately not service design.

I was told about the DataMemberAttribute.Order property by Rory and reluctantly added the Order property to every data contract member. This change still broke the client application. The reason was that the client application was using the XmlSerializer which does not change its behvaior with the new DataMember attributes.

The solution was to serialise a Data Contract using the DataContractSerializer. I still consider this to be a dirty solution because the ordering of the properties must always be the same, otherwise the consumer may break.

Data Contract

The following data contract lists fields in alphabetical order. The Order attribute forces the DataContractSerializer to output elements in the requested order.

Serializing using the XmlSerializer

The XML is written in the order the fields are defined in the class.

Serializing using the DataContractSerializer

    Person person = new Person { Age = 25, FirstName = “Bob”, LastName = “Jane” };

    using (FileStream writer = new FileStream(“Person.xml”, FileMode.Create))

    {

        DataContractSerializer contractSerializer = new DataContractSerializer(typeof (Person));

        contractSerializer.WriteObject(writer, person);

        writer.Close();

    }

 

The XML is written in the expected order defined by the Order property, even though the data contract defines in another order.

So if you require a specific order to be xml serialized, make sure you use the DataContractSerializer.