Configuring a WCF Binding
Recall that each binding provided by WCF can be represented in markup (via a binding XML element such as
<basicHttpBinding> or in code via an identically named class type such as BasicHttpBinding. Regardless of which
approach you take, each binding supports a large number of properties that allow you to control numerous details
including time-out settings, message and buffer sizes, security, text encoding, and so on. Each binding as a set of
default options, which you inherit out of the box. If these do not fit the bill, you can modify them accordingly.
Although many binding share identical properties, each binding also has a set of properties that make sense only
for itself. For example, some bindings have no clue about advanced security options or duplex bindings.
Other bindings have no clue about HTTP-specific settings. The short answer is that each binding type is unique
and can be configured in a unique manner.
Consider the following full schema for the basicHttpBinding. As you can see, it can be configured in a variety of
ways. To be sure, other bindings such as netTcpBinding and netNamedPipeBinding have some unique properties.
<basicHttpBinding>
<binding
allowCookies = "Boolean"
bypassProxyOnLocal = "Boolean"
closeTimeout = "TimeSpan"
envelopeVersion = "None/Soap11/Soap12"
hostNameComparisonMode = "StrongWildCard/Exact/WeakWildcard"
maxBufferPoolSize = "Integer"
maxBufferSize = "Integer"
maxReceivedMessageSize = "Integer"
messageEncoding = "Text/Mtom"
name = "string"
openTimeout = "TimeSpan"
proxyAddress = "URI"
receiveTimeout = "TimeSpan"
sendTimeout = "TimeSpan"
textEncoding = "UnicodeFffeTextEncoding/Utf16TextEncoding/Utf8TextEncoding"
transferMode = "Buffered/Streamed/StreamedRequest/StreamedResponse"
useDefaultWebProxy = "Boolean"
<security mode =
"None/Transport/Message/TransportWithMessageCredential/
TransportCredentialOnly">
<transport clientCredentialType =
"None/Basic/Digest/Ntlm/Windows/Certificate"
proxyCredentialType = "None/Basic/Digest/Ntlm/Windows"
realm = "string" />
<message algorithmSuite = "Aes128/Aes192/Aes256/
Rsa15Aes128/Rsa15Aes256/TripleDes"
clientCredentialType = "UserName/Certificate"/>
</security>
<readerQuotas maxDepth = "Integer"
maxStringContentLength = "Integer"
maxByteArrayContentLength = "Integer"
maxBytesPerRead = "Integer"
maxNameTableCharCount = "Integer" />
</binding>
</basicHttpBinding>
It would be completely impractical to comment on every possible option of every possible binding. You will see
various properties of the bindings as you go along in the class. Like any set of prefabricated code, you learn as
you go. Also be aware that each binding supplies defaults for the defined properties and can therefore be ignored
in many cases.
When you are building WCF hosts and clients, you will need to focus on the binding(s) you care about and consult
the .NET Framework SDK documentation for full details. Simply consult the <bindings> section of the WCF
schema documentation. Here you will find details of each binding property. The number of options is
overwhelming, but remember that in many cases you will only care about one or two possible bindings. Therefore,
you can focus your attention on those items. You simply *must* be willing to read the documentation.
Also, when you use the WCF Configuration Editor, you can create and configure new bindings for your
endpoints. This will help with typos that can occur when directly editing an App.config file. There is also the
benefit of limited designer IntelliSense for many properties. Best of all, this tool will format your configuration file
correctly, rather than forcing you to remember where all the configuration elements must be placed.
When you wish to configure a binding in the host’s configuration file, you can use the WCF editor as follows:
• Define your endpoints as expected.
• Elect to add a new Binding in your configuration file using the Bindings node.
• Here you will be presented with a dialog to pick a binding to tweak.
You can now use the UI editor to configure the binding as you see fit. Once you save your changes, the
configuration file will be updated accordingly.
At this point, you can associate your <endpoint> to your uniquely named binding. Do be sure to give your
custom bindings a unique name. Note the use of the bindingConfiguration attribute in the <endpoint> element.
<?xml version = "1.0" encoding = "utf-8" ?>
<configuration>
<system.serviceModel>
<bindings>
<wsHttpBinding>
<binding name = "myCustomWsHttpBinding"
openTimeout = "00:30:00" />
</wsHttpBinding>
</bindings>
<services>
<service name = "MyLib.MyService">
<endpoint address = "http://localhost:8080/MyService"
binding = "wsHttpBinding"
bindingConfiguration = "myCustomWsHttpBinding"
contract = "MyLib.IMyInterfaceContract" />
</service>
</services>
</system.serviceModel>
</configuration>
Recall that each binding provided by WCF can be represented in markup (via a binding XML element such as
<basicHttpBinding> or in code via an identically named class type such as BasicHttpBinding. Regardless of which
approach you take, each binding supports a large number of properties that allow you to control numerous details
including time-out settings, message and buffer sizes, security, text encoding, and so on. Each binding as a set of
default options, which you inherit out of the box. If these do not fit the bill, you can modify them accordingly.
Although many binding share identical properties, each binding also has a set of properties that make sense only
for itself. For example, some bindings have no clue about advanced security options or duplex bindings.
Other bindings have no clue about HTTP-specific settings. The short answer is that each binding type is unique
and can be configured in a unique manner.
Consider the following full schema for the basicHttpBinding. As you can see, it can be configured in a variety of
ways. To be sure, other bindings such as netTcpBinding and netNamedPipeBinding have some unique properties.
<basicHttpBinding>
<binding
allowCookies = "Boolean"
bypassProxyOnLocal = "Boolean"
closeTimeout = "TimeSpan"
envelopeVersion = "None/Soap11/Soap12"
hostNameComparisonMode = "StrongWildCard/Exact/WeakWildcard"
maxBufferPoolSize = "Integer"
maxBufferSize = "Integer"
maxReceivedMessageSize = "Integer"
messageEncoding = "Text/Mtom"
name = "string"
openTimeout = "TimeSpan"
proxyAddress = "URI"
receiveTimeout = "TimeSpan"
sendTimeout = "TimeSpan"
textEncoding = "UnicodeFffeTextEncoding/Utf16TextEncoding/Utf8TextEncoding"
transferMode = "Buffered/Streamed/StreamedRequest/StreamedResponse"
useDefaultWebProxy = "Boolean"
<security mode =
"None/Transport/Message/TransportWithMessageCredential/
TransportCredentialOnly">
<transport clientCredentialType =
"None/Basic/Digest/Ntlm/Windows/Certificate"
proxyCredentialType = "None/Basic/Digest/Ntlm/Windows"
realm = "string" />
<message algorithmSuite = "Aes128/Aes192/Aes256/
Rsa15Aes128/Rsa15Aes256/TripleDes"
clientCredentialType = "UserName/Certificate"/>
</security>
<readerQuotas maxDepth = "Integer"
maxStringContentLength = "Integer"
maxByteArrayContentLength = "Integer"
maxBytesPerRead = "Integer"
maxNameTableCharCount = "Integer" />
</binding>
</basicHttpBinding>
It would be completely impractical to comment on every possible option of every possible binding. You will see
various properties of the bindings as you go along in the class. Like any set of prefabricated code, you learn as
you go. Also be aware that each binding supplies defaults for the defined properties and can therefore be ignored
in many cases.
When you are building WCF hosts and clients, you will need to focus on the binding(s) you care about and consult
the .NET Framework SDK documentation for full details. Simply consult the <bindings> section of the WCF
schema documentation. Here you will find details of each binding property. The number of options is
overwhelming, but remember that in many cases you will only care about one or two possible bindings. Therefore,
you can focus your attention on those items. You simply *must* be willing to read the documentation.
Also, when you use the WCF Configuration Editor, you can create and configure new bindings for your
endpoints. This will help with typos that can occur when directly editing an App.config file. There is also the
benefit of limited designer IntelliSense for many properties. Best of all, this tool will format your configuration file
correctly, rather than forcing you to remember where all the configuration elements must be placed.
When you wish to configure a binding in the host’s configuration file, you can use the WCF editor as follows:
• Define your endpoints as expected.
• Elect to add a new Binding in your configuration file using the Bindings node.
• Here you will be presented with a dialog to pick a binding to tweak.
You can now use the UI editor to configure the binding as you see fit. Once you save your changes, the
configuration file will be updated accordingly.
At this point, you can associate your <endpoint> to your uniquely named binding. Do be sure to give your
custom bindings a unique name. Note the use of the bindingConfiguration attribute in the <endpoint> element.
<?xml version = "1.0" encoding = "utf-8" ?>
<configuration>
<system.serviceModel>
<bindings>
<wsHttpBinding>
<binding name = "myCustomWsHttpBinding"
openTimeout = "00:30:00" />
</wsHttpBinding>
</bindings>
<services>
<service name = "MyLib.MyService">
<endpoint address = "http://localhost:8080/MyService"
binding = "wsHttpBinding"
bindingConfiguration = "myCustomWsHttpBinding"
contract = "MyLib.IMyInterfaceContract" />
</service>
</services>
</system.serviceModel>
</configuration>
Configuring a Service to Use Multiple Endpoints
Table of Contents
Copyright (c) 2008. Intertech, Inc. All Rights Reserved. This information is to be used exclusively as an
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Courseware
Training Resources
Tutorials
Services