Monday, January 17, 2011

Error while deploying to Windows Azure Devevelopment Fabric

At a customer, after installing the Windows Azure SDK version 1.3 , when we tried to deploy their app on the development fabric, Visual Studio throws us 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.



    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)

We tried a lot of stuff to get it working. In the end we recreated a new solution from scratch to determine what could be the cause of this issue. Of course everything worked. By comparing the 2 solutions we discovered that our newly created solution was targeting the .NET Framework 4.0 while our existing solution was targeting the .NET Framework 3.5. Changing the target framework from .NET 3.5 to .NET 4.0 solved the problem.

UPDATE We followed some tips in the comments and discovered the root cause of the issue. Because we were using TFS source control the web.config was changed to readonly. Removing the readonly bits solved the problem. I guess that by changing the target framework the readonly attribute was removed by Visual Studio itself.


Steve Marx said...

FYI, you should be able to run .NET 3.5 applications fine. I don't know what the cause of the error is, but it's not that .NET 4 is required.

Bart Wullems said...

Hi Steve,
I know. We are guessing that the problem is related to the different web.config used for .NET 3.5 and 4.0. But we were not able to pinpoint the exact cause of the issue.
All tips are welcome!


Steve Marx said...

Any chance your web.config was read-only (maybe under version control), and you made it writable when you edited it? (I believe that's the error you get when you have a read-only web.config.)