What a Binding Actually Configures
In WCF, a binding is the bundle of decisions that determines how a message physically travels between client and service: the transport (HTTP, TCP, named pipes, MSMQ), the encoding (text, binary, or MTOM), and the security, session, and reliability behaviors layered on top. A binding is deliberately separate from the contract (what operations exist) and the address (where the service lives) so the same ServiceContract can be exposed over multiple bindings simultaneously without touching the interface code.
Cricket analogy: Choosing a binding is like choosing the pitch and format for a match: a T20 flat track (fast, low-security netTcpBinding) plays very differently from a seaming Headingley Test pitch (cautious, WS-Security-laden wsHttpBinding), even though the same MS Dhoni-style batting technique (the contract) applies to both.
Common Built-in Bindings
WCF ships with roughly a dozen system-provided bindings, but four dominate real-world usage. basicHttpBinding targets SOAP 1.1 interoperability with legacy ASMX clients and applies weak security by default. wsHttpBinding supports the WS-* stack (WS-Security, WS-ReliableMessaging, WS-AtomicTransaction) over HTTP, making it the default choice for interoperable, secure web services. netTcpBinding uses a binary encoding over TCP for fast intranet communication between .NET services, and netNamedPipeBinding restricts communication to the same machine using named pipes for the lowest possible latency.
Cricket analogy: basicHttpBinding versus wsHttpBinding is like Rohit Sharma opening in a franchise T10 exhibition (fast, loose rules) versus opening in an ICC World Test Championship final (strict regulations, DRS, full protective gear) — same batting role, very different rulebooks.
Choosing Between HTTP and TCP Bindings
The practical decision usually comes down to wsHttpBinding versus netTcpBinding. wsHttpBinding travels over port 80/443, tunnels through corporate firewalls and proxies without special configuration, and interoperates with non-.NET clients because it speaks standard SOAP with WS-* extensions. netTcpBinding requires open TCP ports (typically 808 or a custom port), only works between WCF endpoints since it uses a proprietary binary format, but delivers noticeably lower latency and smaller message sizes because it skips XML text parsing overhead.
Cricket analogy: wsHttpBinding is like playing a bilateral series under full ICC regulations so any nation's team can participate, while netTcpBinding is like an intra-squad practice match at the National Cricket Academy where only insiders with special access are involved.
<system.serviceModel>
<bindings>
<wsHttpBinding>
<binding name="secureWsBinding">
<security mode="Message">
<message clientCredentialType="Windows" />
</security>
</binding>
</wsHttpBinding>
<netTcpBinding>
<binding name="fastTcpBinding" maxReceivedMessageSize="2097152">
<security mode="Transport" />
</binding>
</netTcpBinding>
</bindings>
<services>
<service name="OrderService.OrderProcessor">
<endpoint address="ws" binding="wsHttpBinding"
bindingConfiguration="secureWsBinding"
contract="OrderService.IOrderProcessor" />
<endpoint address="net.tcp://localhost:808/OrderProcessor"
binding="netTcpBinding"
bindingConfiguration="fastTcpBinding"
contract="OrderService.IOrderProcessor" />
</service>
</bindings>
</system.serviceModel>basicHttpBinding defaults to Security mode 'None' for backward compatibility with legacy ASMX web services. If you use basicHttpBinding for anything beyond internal, trusted, non-sensitive traffic, you must explicitly configure Transport or Message security — it will not warn you at compile time that credentials are traveling in plain text.
Custom Bindings
When none of the system-provided bindings fit — for example, you need reliable sessions over plain HTTP without WS-* overhead, or a non-standard combination of transport and encoding — WCF lets you assemble a customBinding by composing individual binding elements such as reliableSession, textMessageEncoding, and httpTransport in a specific stack order. Each system binding like wsHttpBinding is, under the hood, just a convenient shorthand for one of these customBinding compositions, which you can inspect and override element by element.
Cricket analogy: Building a customBinding is like a coach assembling a bespoke fielding formation for a specific batter, say a 7-2 off-side trap against Steve Smith, rather than using a stock field setting — you pick each fielder's position deliberately.
Client and service bindings must match compatibly — same transport, same security mode, same message version. A mismatched binding configuration, such as a client using BasicHttpSecurityMode.Transport against a service configured for Message security, typically surfaces as a confusing runtime exception (often a generic 'could not establish trust relationship' or 400/415 error) rather than a clear configuration error at startup.
- A binding configures transport, encoding, and security independently of the contract and address.
- basicHttpBinding favors legacy SOAP 1.1 interoperability but defaults to no security.
- wsHttpBinding is the standard secure, interoperable choice for cross-platform HTTP services.
- netTcpBinding and netNamedPipeBinding trade interoperability for speed within .NET-only environments.
- Every system binding is really a preconfigured customBinding composition under the hood.
- Client and service binding configurations must match exactly or calls fail at runtime with unclear errors.
Practice what you learned
1. Which WCF binding provides WS-Security, reliable sessions, and transaction support over standard HTTP ports by default?
2. What is the primary limitation of netTcpBinding compared to wsHttpBinding?
3. What is the default security mode of basicHttpBinding?
4. Which binding element combination best describes what a customBinding lets you do?
5. What commonly happens when a client's binding configuration does not match the service's binding configuration?
Was this page helpful?
You May Also Like
Endpoints and Behaviors
How WCF endpoints expose service operations and how behaviors attach cross-cutting runtime policies to services, endpoints, and operations.
WCF Configuration Basics
How WCF services are wired together through web.config/app.config, and the essential Address-Binding-Contract structure behind every endpoint.
Hosting WCF Services
How WCF services get activated and run, from self-hosted console applications to IIS and Windows Activation Services.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics