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
Message=The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it is in the Faulted state.
Source=mscorlib
StackTrace:
Server stack trace:
at System.ServiceModel.Channels.CommunicationObject.Close(TimeSpan timeout)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at System.ServiceModel.ICommunicationObject.Close(TimeSpan timeout)
at System.ServiceModel.ClientBase`1.System.ServiceModel.ICommunicationObject.Close(TimeSpan timeout)
at Microsoft.WindowsAzure.Hosts.WaIISHost.Program.Main(String[] args)
InnerException:
It didn’t make any sense.
Most of the support out there (like here) suggested that it was because I was using a using (...) { } block around a ServiceClient. Something about exceptions that get raised during the ServiceClient‘s Close 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. That wasn’t the case either.
It turns out it was the use of the section in Web.config. What also didn’t help was that I had two sections by mistake as well (the result of a bad merge). According to the Windows Azure SDK Release Notes, “If you wish to use the IIS URL Rewrite module, you must install it and configure your rewrite rules.”
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 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.