WCF Quick Reference

The four bindings used in the overwhelming majority of real deployments are basicHttpBinding (SOAP 1.1 over HTTP, for maximum interoperability with older clients including legacy ASMX consumers), wsHttpBinding (SOAP 1.2 with WS-Security, WS-ReliableMessaging, and transactions, for secure interoperable web services), netTcpBinding (fast binary encoding over raw TCP, for .NET-to-.NET communication within a trusted network), and netNamedPipeBinding (binary encoding over named pipes, for same-machine inter-process communication with the lowest possible latency). Choosing the wrong binding is the single most common WCF misconfiguration: using wsHttpBinding when only .NET clients on the same LAN ever connect adds unnecessary SOAP overhead, while using basicHttpBinding when WS-Security is required leaves the service without proper message-level protection.

The essential attribute set every developer needs memorized: [ServiceContract] on an interface (optionally with a Namespace property to avoid the default tempuri.org), [OperationContract] on each method meant to be callable remotely (methods without it are invisible to clients), [DataContract] on classes passed as parameters or return values (with an optional IsReference for circular object graphs), and [DataMember] on each field or property that should actually be serialized, with an optional Order property to control serialization sequence when strict ordering matters for interoperability with non-.NET clients. A subtlety worth remembering is that without [DataContract]/[DataMember], WCF falls back to the more permissive DataContractSerializer's implicit serialization of all public read/write properties, which works but gives less control over the wire format.

WCF services can be self-hosted in a console app or Windows Service using ServiceHost, hosted in IIS as a .svc file with ASP.NET compatibility, or hosted via Windows Activation Service (WAS) which additionally enables non-HTTP bindings like netTcpBinding inside IIS. Configuration lives in <system.serviceModel> in app.config/web.config with three key sub-sections: <services> (which contract each service class implements and which endpoints it exposes), <bindings> (named binding configurations with custom timeouts, message sizes, and security settings), and <behaviors> (cross-cutting settings like serviceMetadata for MEX/WSDL exposure and serviceDebug for detailed fault information during development, which must be disabled in production to avoid leaking stack traces).