I've been developing in MS technologies for longer than I care to remember at this stage. When .NET arrived on the scene I thought they hit the nail on the head and with each iteration and version I thought their technologies were getting stronger and stronger and looked forward to each release.

However, having had to work with WCF for the last year I must say I found the technology very difficult to work with and understand. Initially it's quite appealing but when you start getting into the guts of it, configuration is a nightmare, having to override behaviours for message sizes, number of objects contained in a messages, the complexity of the security model, disposing of proxies when faulted and finally moving back to defining interfaces in code rather than in XML.

It just does not work out of the box and I think it should. We found all of the above issues while either testing ourselves or else when our products were out on site.

I do understand the rationale behind it all, but surely they could have come up with simpler implementation mechanism.

I suppose what I'm asking is,

• Am I looking at WCF the wrong way?
• What strengths does it have over the alternatives?
• Under what circumstances should I choose to use WCF?

OK Folks, Sorry about the delay in responding, work does have a nasty habbit of get in the way somethimes :)

Some clarifications My main paint point with WCF I suppose falls down into the following areas While it does work out of the box, your left with some major surprises under the hood. As pointed out above basic things are restricted until they are overridden

1. Size of string than can be passed can't be over 8K
2. Number of objects that can be passed in a single message is restricted
3. Proxies not automatically recovering from failures
4. The amount of configuration while it's there is a good thing, but understanding it all and what to use what and under which circumstances can be difficult to understand. Especially when deploying software on site with different security requirements etc. When talking about configuration, we've had to hide lots of ours in a back-end database because security and network people on-site were trying to change things in configuration files without understanding it.
5. Keeping the configuration of the interfaces in code rather than moving to explicitly defined interfaces in XML, which can be published and consumed by almost anything. I know we can export the XML from the assembley, but it's full of rubbish and certain code generators choke on it.

I know the world moves on, I've moved on a number of times over the last (ahem 22 years I've been developing) and am actively using WCF, so don't get me wrong, I do understand what it's for and where it's heading.

I just think there should be simplier configuration/deployment options available, easier set-up and better management for configuration (SQL config provider maybe, rahter than just the web.config/app.config files).

OK, back to the daily grid.

Thanks for all your replies so far.

Kind Regards Noel