Adventures while building a Silverlight Enterprise application part #41

In this post we dive into this tiny change that caused a weird bug in the WCF communication between our Silverlight client and one of our web services.

In the last post I mentioned we were about to go live with a new product. It’s my pleasure to report we have gone live since then and everything is going well, except for some minor issues. I also described a process where we would do to improve our development process. At this point we are in full swing with doing that.

While we are doing that, we have also planned a new release to fix the minor issues I mentioned before and add some small features for which we didn’t have the time earlier. As I was working on a bug fix for one of these issues, I ran into a bug that puzzled me at first, but once I figured it out was trivial. Because it took a fair amount of debugging and analyzing to get to it and it highlights a problem with refactoring some parts of your code, I figured I’d share it with all of you.

Sypmtoms

As I was testing this bug fix I had been working on, I ran into some weird behavior. Some of the data in the Silverlight client would not load, or so it seemed. At first I thought this might have something to do with the fix I did.

I started debugging the service I had changed and found out that, for some reason an id we send to the service in order to get the right data in, was empty. This was weird, because I didn’t change anything to that part of the code. I debugged the Silverlight client and found out that it did send the id correctly! That was weird. The only thing I could conclude was that the id must have been getting lost somewhere along the line between the code on the client and the code in the web service.

Debugging the issue

As this appeared to be some kind of a communication issue, I figured I’d break out my old friend Fiddler. I reconfigured the client to access the web service involved through http://ipv4.fiddler, instead of http://localhost and I started reproducing the problem. I browsed through the requests and there it was, the parameter named Id was correctly being transferred and had the right value. For some reason though that value was gone as soon as it reached my web service.

The only conclusion I could make at this point was that it had to have something to do with the service contract. I took a look at the the interface for my service and immediately I spotted a potential problem. The parameter was not called Id anymore, but it was renamed to id! This was done as a result of a warning produced by FxCop. It marked the casing of the parameter name as incorrect, so I corrected it, but then completely forgot about it.

An easy fix

In order to get this fixed, I made sure the casing in my .svc code behind was corrected as well. Then it was all a matter of rebuilding and publishing the service and refreshing the service reference in the Silverlight client and the problem was gone.

As it turns out it was a good idea to do a release on the cleaned up code, because this way we run into some of the consequences early on. It also shows that there is always a danger to changing service contracts, because it creates incompatibilities that might not be so easy to spot.