That confounded WCF configuration file

The great thing about Visual Studio is that it pampers you, by doing a fantastic job on your behalf to hide all the nitty-gritties.  The downside is that when you depart from the default values/names/settings, you may not know what manual changes are needed.

If you have read Keith Elder's article about WCF, you will understand what a Boeing 747 you have.  And you need a lot of new skills to pilot such a plane.  I would like to share some basics about web.config/app.config that I learned the hard way.

The new section of interest in the configuration file is: <system.serviceModel>.   You can have nothing in this section, and everything will simply take on certain default values.  The commonly used elements in this section are:

• <services>
• <bindings>
• <behaviors>

<services>

The <services> section defines the web services you want to publish. (On the client's web.config, you would not have this but a <client> section instead.) The <services> element contains the <service> elements (that's how subtle and confusing the names can be if you read too fast).

For each web service you have in your project, though optional, you should have a corresponding <service> element defined. If your web service code is like:

namespace NNNN
{
   [ServiceContract]
   public interface CCCC
   { ...

and the implementation:

namespace NNNN
{
   public class SSSS : CCCC
   { ...

then an example of your <service> element can be as follows:

<services>
 <service name="NNNN.SSSS"   behaviorConfiguration="BBBB">
    <endpoint address=""   binding="basicHttpBinding"   bindingConfiguration="BCBC"
    <contract="NNNN.CCCC" />
 </service>
</services>

BBBB points to a <behavior> element in your configuration file, while BCBC points to a binding element in the same file.  In other words, BBBB, if it is specified in the service, must be in the name attribute of a <behavior> element in the <behaviors> section, and similarly BCBC must be in the name attribute of a binding element in the <bindings> section. Otherwise, you will get an error when you try to call anything on the host.

One thing I find odd is the need for the binding attribute in the <endpoint> element.  It is not free text, but must be one of the valid binding types.  But the binding type is already defined in the binding element (see below) referred to in the bindingConfiguration attribute of the endpoint.

A service can have zero or one or more endpoints explicitly defined.

<bindings>

The elements in the bindings are not named <binding> but must be one of the valid WCF binding types. So, they could be <basicHttpBinding>, <webHttpBinding>, and so on.  (Use Intellisense in Visual Studio to see the full list.)  For my above example, you can use something like the following to make use of integrated Windows authentication:

<bindings>
  <basicHttpBinding>
    <binding name="BCBC">
      <security mode="TransportCredentialOnly">
        <transport clientCredentialType="Windows" />
      </security>
    </binding>
  </basicHttpBinding>
</bindings>

You may need to look up further documentation on what other values you can have in <security> or <transport>, and other elements you can add.

<behaviors>

I have not learned what behaviors web services can have other than the one use to publish meta data.  Meta data is the information that your client can use to determine the web methods and data types that are available from the web service.  If your clients are using .NET WCF, then a behavior such as below will expose the meta data:

<behaviors>
  <serviceBehaviors>
    <behavior name="BBBB">
      <serviceMetadata httpGetEnabled="true" />
    </behavior>
  </serviceBehaviors>
</behaviors>

Conclusion

I hope the above gives you an introduction to the intricacies of the WCF configuration file. With the basics out of the way, you will be able to explore the esoteric options and attributes.