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>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:
public interface CCCC
public class SSSS : CCCC
<service name="NNNN.SSSS" behaviorConfiguration="BBBB">
<endpoint address="" binding="basicHttpBinding" bindingConfiguration="BCBC"
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:
<transport clientCredentialType="Windows" />
<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:
<serviceMetadata httpGetEnabled="true" />