WCF Service References Generating Empty Proxy Classes

WCF has, admittedly, given me more problems that any other .NET technology I've encountered. This is probably my fault, since a colleague of mine, Scott Seely, was on the WCF team during his blue badge days, and could answer all my questions immediately. In other words, I never had to figure anything out on my own, so I never really learned it.

For example, take the issue I want to discuss in this post: empty reference.cs (or reference.vb) classes in your service references. This would happen to me all the time, and I would whine and bitch about WCF sucking, and Scott or Rupp or Josh would just fix it for me, probably half out of pity and half out of annoyance.

Thanks guys!

Anyways, in my current project, I'm making heavy usage of WCF, and am finally coming around on the technology. Now that I actually get what a binding is, and how it pertains to an endpoint, I can finally embrace WCF as truly the next generation of service applications. You know you're on board with WCF when ASMX suddenly seems like kind of a weenie technology in comparison.

However, that's not to say that WCF isn't a dick sometimes, and refuses to play nicely. Every once in a while, I'll add or update a service reference to/in a project, and the generated proxy class is blank. (...Save for the five commented-out lines at the top of the file stating that it was generated by a tool - isn't that the truth!)

So all I want to do here is provide a checklist of likely causes of this situation. In general, the problem is caused not by the WCF serializer failing, per-say, but rather getting confused. If there is actually a problem, you'll get an error in Visual Studio. However, quietly generating blank proxy classes is a different issue. Here are some things to check when you're getting empty proxy classes, sorted by sanity:

• Navigate to "C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin" and run "SvcUtil.exe." This is always your first line of defense against WCF weirdness. SvcUtil.exe will give you the most detailed exceptions. The biggest cause here is, like I said, the serializer getting confused, such as referenced types not matching, not being properly decorated, etc.
• Make sure your DLLs are in the bin folder on the server. One time I was using a WCF Service Library project, which was putting the assemblies in \bin\release. So when I copied my bin folder to the server, the DLLs were in \bin\release, not bin! You'd think that would blow up, but instead it causes WCF to die quietly.
• Make sure none of your classes (that are decorated as DataContracts for your services) are hanging around in stale assemblies in the GAC. This will cause possible type mismatches. As a SharePoint guy, I'm very used to GACing everything in sight; this is not the case for WCF!
• Decorate, decorate, decorate! If you forget an EnumMember or DataMember attribute, WCF might barf. Note: this is apparently no longer required in .NET 3.5 SP1, but I still put it in.
• Finally, if all else fails, cycle Visual Studio. I once had an cantankerous service that refused to spit out any code in the proxy class. I checked EVERYTHING. Then, in a last-ditched effort, I closed VS, opened it back up, and son-of-a-bee, it then worked!
• [UPDATE]: Another cause I've found has been issues with TFS holding onto generated files. Deleting them in Team Explorer didn't help; I had to remove the project, rename the folder, create a new project with the same name, then copy everything back. Look for this possiblity when *some* projects will correctly generate service references, while others won't.
• [UPDATE]: If you have an assembly containing domain objects that both the service and the consumer project reference, the types need to be identical, or the serializer will get confused and generate a blank proxy class. In my case, I updated a domain object, redployed it to the server, but left the old version in my local GAC. SvcUtil worked fine. It appears as though Visual Studio was generating against the GACed assembly instead of the referenced assembly. So make sure to clear any stale referenced assemblies from the GAC. (I also had to do an IISRESET and cycle Visual Studio to force it to generate against the project-referenced assembly.)

Have fun!