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.

Comments

Post a Comment

Popular posts from this blog

Attack Lab - Level 5 explained

Image
Ning Wang has published a very good write-up (2022 update: web page is gone now) on his solutions to the Attack Lab from the CS:APP book. However, I thought his solution to Level 5 could do with a bit more elaboration for those who are struggling with this topic. First, it is necessary to understand what ROP requires. An essential component of ROP is good luck, lots of it. Without getting lucky, you may take more than 10 100  years to find a workable attack, if at all. This, the authors of CS:APP did not mention. I also could not comprehend the purpose this exercise is even given out as homework in CMU to be completed in a week (while there are tons of homework from other courses too), without an intensive course in Intel Assembler as a prerequisite. Level 5 requires the same general logic as Level 3, which can be summarized as (pseudo code): mov <cookiestring address>, %rdi //why? because touch3 is expecting it there call touch3 To achieve the above for Level 5, ...
Read more

Assembly version, File version, Product version

Image
If you are a .NET developer, Assembly and File version would be familiar to you. They can be set in the Designer UI (project Properties page, Application tab, Assembly I nformation button...) which basically updates appropriate attributes in AssemblyInfo.cs. Now, there is a less well known number - the Product version . It is not well documented and most developers ignore it altogether with no side-effects most of the time. However, it is an important number and it seems that, of the three, Product version is the most widely used. The three version numbers simply take the values you give them or: a. If Assembly version is not explictly specified, it takes the value of 0.0.0.0. b. If File version is not explicitly specified, it takes the value of Assembly version. c. If Product version is not explicitly specified, it takes the value of File version. In Windows Explorer of Windows XP and Server 2003, you can see from the properties of a file all three version numbers. In W...
Read more

Setting to English for the Xiaomi Wifi Router

Image
The Xiaomi Mi Wifi Router now is in English. If it boots up to a foreign language for you, this guide will help you to change it to English. It is best to connect to it via wired Ethernet for the first time. Otherwise, the default unsecured wifi SSID should be Xiaomi_C3C1 . Your IP should be in the subnet 192.168.31.x, and the router is at http://miwifi.com which the router will resolve to 192.168.31.1. The first screen you see will be the setting up of the wifi SSID and wifi password. The big blue button at the bottom is the Next button. The next screen sets up the router administrator password (second field). The first field is Home/Work/Custom. Click the big blue button to complete. At the main configuration page, look for the third item (Settings) on the top menu, and the orange option (System Status): The last option on the page is the language selection: Open the drop down to select English: The change will take place the moment you click English. Enj...
Read more