Azure 1.3, Rewrite module and a 'Faulted' System.ServiceModel.Channels.ServiceChannel

I recently updated to Azure SDK 1.3. Then I tried to debug my solution locally. This is where the trouble began. The problem was that I was using the IIS Rewrite module without having it installed. Rewrite was part of Azure SDK 1.2, but it has to be installed separately for 1.3. I guess I should have read the release notes.

Here is what the problem was, and how I found the solution.

I would consistently get the following exception:

System.ServiceModel.CommunicationObjectFaultedException was unhandled<br></br>
  Message=The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it is in the Faulted state.<br></br>
  Source=mscorlib<br></br>
  StackTrace:<br></br>
    Server stack trace:<br></br>
       at System.ServiceModel.Channels.CommunicationObject.Close(TimeSpan timeout)<br></br>
    Exception rethrown at [0]:<br></br>
       at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)<br></br>
       at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)<br></br>
       at System.ServiceModel.ICommunicationObject.Close(TimeSpan timeout)<br></br>
       at System.ServiceModel.ClientBase`1.System.ServiceModel.ICommunicationObject.Close(TimeSpan timeout)<br></br>
       at Microsoft.WindowsAzure.Hosts.WaIISHost.Program.Main(String[] args)<br></br>
  InnerException:```

It didn’t make any sense.

Most of the support out there (like [here](http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/fc60cd6d-1df9-47ff-90a8-dd8d5de1f080)) suggested that it was because I was using a <tt>using (...) { }</tt> block around a <tt>ServiceClient</tt>. Something about exceptions that get raised during the <tt>ServiceClient</tt>‘s <tt>Close</tt> method being swallowed up into that generic one. But it wasn’t that. My code didn’t consume any WCF services.

I thought it might have been the Facebook SDK. It couldn’t have been log4net or Netwonsoft.JSON, either.

Another suggestion was that WebRole’s [Web.config file was not writeable](http://social.msdn.microsoft.com/Forums/eu/windowsazuretroubleshooting/thread/26165c71-f941-4d84-9ef3-649d7bab0066). That wasn’t the case either.

It turns out it was the use of the <rewrite> section in Web.config. What also didn’t help was that I had two <connectionstrings> sections by mistake as well (the result of a bad merge). According to the [Windows Azure SDK Release Notes](http://msdn.microsoft.com/en-us/library/gg465715.aspx#IIS), “If you wish to use the IIS URL Rewrite module, you must install it and configure your rewrite rules.”</connectionstrings></rewrite>

Once I installed that, I was able to run my solution with the Rewrite rules intact.

I suspected that the problem wasn’t really that the IIS Rewrite module hadn’t been installed, but that the unrecognised Web.config section caused it to fall down. That suspicion was confirmed when I added a <foo></foo> element to my Web.config. The exact same CommunicationObjectFaultedException was raised.

So the golden rule is to your Web.config if you get a CommunicationObjectFaultedException when running an Azure solution locally.