Oh The Pains of WCF

I've written plenty about WCF, most of it negative, some if it positive, but all of it encouraging: despite whatever issue I was facing, I always ended up being able to blast thought it, or at least circumvent it. But this encouragement has now run out. I have spent too many "courageous" nights fighting fighting fighting to get WCF to return data to me from a distant computer.

I really want to like WCF. I want to shutter with anxiety whenever I'm faced with ASMX, the way I would if forced to deal with SharePoint 2003. But "(400) Bad Request" error after "HTTP request is unauthorized with client authentication scheme..." error only make me miss ASMX. And I am a bleeding-edger; a purist when it comes to technology! If my company's clients aren't ready to run the latest version of something and I know I won't get that experience at work, I'll choose some inefficiency in my life and write software with that new technology to solve it.

And I tried and tried with WCF...for years now. The whole thing is like an old favorite band of yours coming out with a new album. Lots of hype and a good single excited you. But when you finally give it a listen, this new record is different than what you expected. It's like the band tried to radically change their music by adding more instruments, heavier sound, and poppier lyrics. It's garbage. And you want to like it. You want to go to their shows because you love them. But every time you hear one of their old classics, you wonder, "It used to be so good; why are they trying so hard now?"

That's how I feel. WCF is certainly more robust than ASMX: more configuration, more flexibility, more support. But do we need it? Perhaps I'm alone inasmuch as 95% of what I need web services for are reading and writing data to and from NTLM-ed Windows environments, (like SharePoint 2010) and 5% are anonymous (for Silverlight). I know WCF tells a better story in .NET 4.0, but not a lot of backend systems support the latest version of the framework yet (like SharePoint 2010).

Like I said, this is good stuff. It forces you to be diligent (I'd even use the word "mature" here) with security. It gives you a lot of control over the wire. I just feel like the default configurations are never what I need; every project requires me to customize something. I'm now spending a lot more time in IIS; a lot more time copy-and-pasting large chunks of XML around from project to project; a lot more time writing code to expose exceptions elegantly; a lot more time updating service references; a lot more time attaching to W3WP processes.

Last night I was working on a SharePoint 2010 timer job that was syncing profiles from a SharePoint 2007 SSP (ASP.NET 3.5, custom ASMX services) to a web application's database (ASP.NET 4.0, WCF, .NET RIA Services). It pulled about 3,000 profiles from the SharePoint 2007 ASMX endpoint just fine, and blew up upon transmitting those to the web app via WCF. Out of the gate I got a timeout, so I increased all four timeout values (OpenTimeout, SendTimeout, CloseTimeout, and ReceiveTimeout) to, I don't know, let's say, 10 minutes? Is that long enough?

(And by the way: this was already on a test server; things worked just fine in development (like they always do). So there was a full deployment between each step.)

Then I got the error that the MaxReceivedMessageSize was exceeded, so I increased that arbitrarily to int.MaxValue. (Check out the "Remarks" section on the MSDN page I just linked to. They actually mention how this thwarts hackers!)

Next I was informed that my graph had too many objects in it. ('Maximum number of items that can be serialized or deserialized in an object graph is '65536'. Change the object graph or increase the MaxItemsInObjectGraph quota.) Unless you are writing bank or government-grade software, who has requirements / estimates / any IDEA what this number should be? So I maxed it out.

Finally, one of the methods on my service started working now. Phew. WCF rules. But then the fun came; the other method on the same service decided that:

WCF sucks.

Either something in the Windows authentication subsystem is sociopathicly case sensitive, or this error message is evidence that WCF was just plain giving up at this point. (I saw something about this error being legit in terms of IIS 6.0, but that's far beyond what my problem could be.) To get all the configuration correct on both sides (client and server) only to get this dreaded error when the authentications actually match?? That just hurts.

And beyond that, you're telling me that one method works, and the other returns a 401? REALLY? That's not possible; same service, same caller, no impersonation. So I tried it again. This time the error was something about sockets that I didn't even bother looking up. Then two more 401's. Then sockets again. After a string of meaningless "(400) Bad Request" errors, I gave up, and redesigned the service to chunk the profiles into groups of 100 for transmission to and from WCF. That worked. All the while, the old ASMX service hummed along just fine.

So what's the moral of the story? I don't know. Am I saying don't use WCF? No. Am I saying that it's too damn hard and wastes a lot time (compared to ASMX)? Yes. Am I'm going to switch from WCF back to ASMX? No. Am I complaining too much? Probably. But in all seriousness, I'd prefer to have the control over my service layer that WCF gives me than not. And ASMX is certainly not without its faults (pun intended). So if you're using WCF (which could indeed stand for Windows Configuration Foundation), heed my advice: keep it small and keep it simple.