Friday, October 3, 2008

Sneaky little WCF error

I was going to drop a post about a WCF issue that had the team scratching their head yesterday afternoon and this morning. However one of the guys on the team spotted this article.

Basically we didn’t validate properly before we threw some enums over the wire, but it would have been nice for WCF to give us an error besides “Connection was closed unexpectedly” which doesn't really lead you to think that a serialization issue is to blame.

3 comments:

Unknown said...

This will not help in this situation but WCF will not give out the error by default. Because it is a communication framework it assumes the worst and will not pass exceptions over the wire as it does not know the client is: ie you can not pass a CLR exception to java. You need to wrap your exceptions as faults* as pass them and you need to mark your contract with faults it can pass back (which is tedious for internal apps). If you do all this then the only exceptions you are left with are serialisation issues which can be easily checked. To Do this ihave in the past set up a test that reflects over my DTO and Message namespaces and confirm they all are serialiseable and data contracts. I dont go to the point of data member checks as this will usally be highlighted by a default value(null/0) on the client side.
* Or you can be lazy and config to send exceptions accross the wire, just dont do this for live.

Lee Campbell said...

Thanks for that feedback. You are completely right about sending exceptions over the wire. I suppose I just thought that some sort of generic fault that mentioned a serialization problem was in order. The colleague that found the error also later pointed out that setting up some WCF tracing made identifying these bugs alot easier.

Anonymous said...

Rhysc - You are correct however It's somewhat of a design flaw that no exception is thrown server side.

The only way I've found to diagnose this type of error is to enable tracing via the WCF configuration file.

This basically means if you were running a server you have to always have tracing on. Otherwise you are relying on your clients to tell you that something has gone wrong.

I'd have liked to be able to do something like this.

ServiceHost.ChannelErrorEvent +=