When developing applications in Silverlight it is inevitable that you will need to perform a request back to the server for data or processing. The common practice is to use Windows Communication Foundation (WCF). I find that WCF usually handles all of my needs and it works well when everything is happy and just right. However, if anything is not in its correct place, we can have tons of problems. Worse yet, we get your all time favorite message back in Silverlight stating:
“Server not found.”
Basically, WCF is telling us to go screw ourselves but in a much more politically correct way. Well there are several ways to attack this problem but I want to show you what I have come to love and use for all my projects involving WCF and Silverlight.
To give us some background, please review the following MSDN reference concerning Creating and Handling Faults in Silverlight. This article explains why we get our beloved message from WCF and what we can do about it. I think this is a must read for anybody wanting to understand what is going on and how they can go about fixing it themselves. I don’t think this is be the best solution but I do think it is a great reference. The reason for looking for something else is that I would like a solution that is a little easier to use and has less configuration required. I tend to follow this pattern because I have clients that want elegant solutions but they want it to be the least disruptive to their development process as possible.
Let’s move to the next blog post that I find very instrumental in dealing with exceptions in WCF. Oleg Sych wrote an excellent article, Simplifying WCF: Using Exceptions as Faults, back in 2008 that I believe is still very pertinent for us today. His solutions is very similar to the MSDN article that we already looked at but I believe it is more comprehensive and provides a good code base with which to use if you wanted to take his approach. I like what I read here but I still wanted something a little less intrusive from the perspective of ceremony and configuration.
This leads us to our last blog post. Here we find Jeroen Bernsen’s entry WCF ExceptionHandling in Silverlight. Like the other two articles, this post tries to solve the problem of dealing with exceptions thrown in WCF and how to get them back to the client in a friendly and easy way. If you read his post, you will see that you only need to create few objects to get our solution working and there is no need to modify your weg.config like in the other solutions. This is the reason why I like this solution the best.
I am going to provide the code below but you can also just follow along Jeroen’s post if you like.
The following class tells WCF to send fault messages with a 200 instead of a 500 response code. This change enables Silverlight to read the body of the message.
public class WcfSilverlightFaultBehavior : IDispatchMessageInspector
{
public void BeforeSendReply(ref Message reply, object correlationState)
{
if (reply.IsFault)
{
HttpResponseMessageProperty property = new HttpResponseMessageProperty();
// Here the response code is changed to 200.
property.StatusCode = System.Net.HttpStatusCode.OK;
reply.Properties[HttpResponseMessageProperty.Name] = property;
}
}
public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext)
{
// Do nothing to the incoming message.
return null;
}
};
Read more: Matt Duffield
0 comments:
Post a Comment