For anyone new to WCF, this probably is the most common question they get. Why do we need MessageContract when DataContract can do the job?

A very simple answer to the question is, when you need a higher level of control over the message, such as sending custom SOAP header, you then use MessageContract instead of DataContract. But in my opinion, most of the messaging needs can be catered by DataContracts.

This is the extract from MSDN : Sometimes complete control over the structure of a SOAP message is just as important as control over its contents. This is especially true when interoperability is important or to specifically control security issues at the level of the message or message part. In these cases, you can create a message contract that enables you to use a type for a parameter or return value that serializes directly into the precise SOAP message that you need.

To elborate on the above mentioned MSDN extract, a message contract allows you to specifically control which elements will be in the SOAP header, and which will be in the SOAP body and this isn't possible using the DataContract. As DataContracts represent types. Messages are not used as types but rather the payload a method operates on and they are specific to the operation they are passed to and from.

This situation arises when you have a communication partner which requires a very specific format and you have to tweak your SOAP messages to match that given layout exactly. In my view, always use DataContracts unless you have to use MessageContract for a very good reason.

One of the hypothetical situation could be your communication partner would like to have a custom security header with username and hashed password. So you could have a message contract something similar to the below

[MessageContract]
public class BankingTransaction
{
  [MessageHeader] public string UserName;
  [MessageHeader] public string Password;
  [MessageBodyMember] private Account sourceAccount;
  [MessageBodyMember] private Account targetAccount;
  [MessageBodyMember] public int amount;

}

Notice on the above contract the UserName and Password are decorated with MessageHeader attribute. The generated SOAP message with WCF basicHttpBinding will look like following:

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header>
    <Action s:mustUnderstand="1" 
xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">
http://tempuri.org/IService1/MoveAccountData
</Action>
    <h:Password xmlns:h="http://tempuri.org/">HashPassword</h:Password>
    <h:UserName xmlns:h="http://tempuri.org/">TestUser</h:UserName>
  </s:Header>
  <s:Body>
    <BankingTransaction xmlns="http://tempuri.org/">
      <amount>10</amount>
      <sourceAccount>1234</sourceAccount>
      <targetAccount>5678</targetAccount>
    </BankingTransaction>
  </s:Body>
</s:Envelope>

Notice the SOAP the password and username members are serialized as SOAP header and the remaining members were serialized as SOAP body.

This was just one of the e.g. of the level of control that could be achieved by MessageContract. There are other controls such as encrypting or signing part of the messages, but that could be a blog post for another day.

Sometimes on hosting WCF service on IIS7.0 you might receive the following error

HTTP Error 404.3 – Not Found

The page you are requesting cannot be served because of the extension configuration. If the page is a script, add a handler. If the file should be downloaded, add a MIME map. Detailed Error InformationModule StaticFileModule.

This happens when IIS7.0 doesn't know how to handle the .svc files. To fix this we need to register WCF with IIS7.0, following are the steps:

1. Run Visual Studio 2008 Command Prompt as “Administrator”.
2. Navigate to C:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation.
3. Run this command servicemodelreg –i.

The servicemodelreg is a command line tool which provides the ability to manage the registration on ServiceModel on a machine. There is more info on this commans on MSDN here.