none
Error deploying locally 29 November 2010 Azure Tools

    Question

  • Hi, I updated the version of the tools to the november release, I installed both VSCloudService.exe and WindowsAzureSDK-x64.exe (Version 1.3 of the platform)

    After installing them, when I try to deploy an app on the development fabric, Visual Studio throws me 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:

    How can I fix this problem?

    I'm using

    • VS2010
    • Windows 7 Ultimate
    • x64 machine
    • All updates from windows update installed.

    Ask me if you need more info.

    Tuesday, November 30, 2010 2:41 PM

Answers

  • FIXED!!!!!!!!!!!!!!!!!!!!!!!!

    This issue drove me crazy for the last day; Microsoft owes me a beer for this fix! :) So after much weeping and gnashing of teeth, I figured out what the fix is:

    Make sure your web role web.config is writable (i.e. not locked in read-only by source control or the read-only file bit.)

    It looks like there is a bug in the Azure SDK 1.3 that is causing the web.config to be written to during the instantiation of the Azure dev fabric roles. If the web.config is read-only, Azure is blocked from editing the file (no actual edits take place that I can find) and the bizarro System.ServiceModel.CommunicationObjectFailedException message bubbles up.

    Secondarily.... Make sure that any <system.web><httpModule> declarations are moved to <system.webServer><modules>. This was a minor issue causing a few hiccups (not the main problem), but I thought it was worth mentioning.

    Hope that helps everyone.

    Aaron

    • Proposed as answer by Thomas Phlips Wednesday, December 01, 2010 7:21 AM
    • Marked as answer by Mog Liang Tuesday, December 07, 2010 8:52 AM
    Wednesday, December 01, 2010 2:50 AM

All replies

  • I know this may sound unlikely given the exception, but I recently saw this same message when I accidentally defined a duplicate (system.diagnostics) section defined in a web.config file. Make sure that your config file is valid.
    Tuesday, November 30, 2010 4:45 PM
  • got this one too...
    -- My Azure Sites: www.eblizz.com , www.freshfugu.com Blog: martinatsunset.com Twitter: martin_sunset
    Tuesday, November 30, 2010 4:59 PM
  • No duplicate system.Diagnostics in web.config. Also think that the web.config is valid, but is there any way ti validate it automatically?
    Tuesday, November 30, 2010 5:10 PM
  • I upgraded my project today as well from 1.0 to 1.3 => exact same problem, no solution yet ... tried (almost) everything.

    We're using Entity Framework, WCF Ria Services, Silverlight clients

    Everything worked smoothly in Azure SDK 1.0.

    Tuesday, November 30, 2010 10:38 PM
  • seen this before, I think when upgrading from 1.0 to 1.2, but never overcame the issue. Eventually gave up and started in a blank machine (well, that's the advantage using VMs for development...).

    Sorry no real solution, but maybe thats a good point in time to start with a clean machine ;)

    Tuesday, November 30, 2010 11:02 PM
  • I'm getting the same error after upgrading as well. My project was working fine prior to the upgrade. I downloaded the upgrade and installed it and I can no longer run locally. Here is the full 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: Visual Studio 2010 Professional Windows 7 Professional No WCF in our project
    Wednesday, December 01, 2010 2:20 AM
  • FIXED!!!!!!!!!!!!!!!!!!!!!!!!

    This issue drove me crazy for the last day; Microsoft owes me a beer for this fix! :) So after much weeping and gnashing of teeth, I figured out what the fix is:

    Make sure your web role web.config is writable (i.e. not locked in read-only by source control or the read-only file bit.)

    It looks like there is a bug in the Azure SDK 1.3 that is causing the web.config to be written to during the instantiation of the Azure dev fabric roles. If the web.config is read-only, Azure is blocked from editing the file (no actual edits take place that I can find) and the bizarro System.ServiceModel.CommunicationObjectFailedException message bubbles up.

    Secondarily.... Make sure that any <system.web><httpModule> declarations are moved to <system.webServer><modules>. This was a minor issue causing a few hiccups (not the main problem), but I thought it was worth mentioning.

    Hope that helps everyone.

    Aaron

    • Proposed as answer by Thomas Phlips Wednesday, December 01, 2010 7:21 AM
    • Marked as answer by Mog Liang Tuesday, December 07, 2010 8:52 AM
    Wednesday, December 01, 2010 2:50 AM
  • Also think that the web.config is valid, but is there any way ti validate it automatically?


    I don't know why Visual Studio 2010 doesn't tell you that the Web.config file is invalid. I seem to remember that earlier versions were better at this. But one way to see if you have an invalid configuration file is to open IIS Manager. If you run your web role project, you will see that it creates a new site in IIS to host your deployment. In the features view, double-clicking any of the configuration items, for example, Default Document, immediately tells you if the configuration file is not well formed.

    I would suggest that you also try browsing the site before dismissing the error in Visual Studio. In my case, the duplicate element in web.config was causing an HTTP 500 Internal Server Error. I assume that there is some behind-the-scenes WCF communication between WaIISHost.exe--the role entry point--and IIS and when the site fails to start due to an internal error, it triggers this particular exception.

     

    Wednesday, December 01, 2010 3:13 AM
  • Hi Aaron,

    Interesting, a read-only web.config triggers the error too. I can confirm that.

    Wednesday, December 01, 2010 3:20 AM
  • I was excited to try this out and made my web.config writeable but I still received the error.  I made every single file writeable and I'm still receiving the same error.  If I try to run without debugging, waiishost.exe crashes:

     

    Problem signature:
     Problem Event Name:	CLR20r3
     Problem Signature 01:	waiishost.exe
     Problem Signature 02:	1.0.0.0
     Problem Signature 03:	4cea2d83
     Problem Signature 04:	System.ServiceModel
     Problem Signature 05:	4.0.0.0
     Problem Signature 06:	4ba1f498
     Problem Signature 07:	e0
     Problem Signature 08:	c4
     Problem Signature 09:	I0SHPZEWVQV4P1UJY40X15MQTHF34RR5
     OS Version:	6.1.7600.2.0.0.256.48
     Locale ID:	1033
     Additional Information 1:	5f30
     Additional Information 2:	5f306f9dd98660815880a580b10df886
     Additional Information 3:	aa68
     Additional Information 4:	aa680fd049e4077986cd40c40182d8da
    
    Read our privacy statement online:
     http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409
    
    If the online privacy statement is not available, please read our privacy statement offline:
     C:\Windows\system32\en-US\erofflps.txt
    

     

    Wednesday, December 01, 2010 3:39 AM
  • Here is a little more information.  I opened the Azure Compute Emulator and noticed that when the exception happens (System.ServiceModel.CommunicationObjectFaultedException was unhandled) the Web Role starts but as soon as I click continue the role stops.  I tried browsing to the site before clicking continue and I received a 500 "Cannot read configuration file due to insufficient permissions" and it shows the path to my web.config (though the path to it starts with \\?\C:\ but I'm not sure if that's an issue.  I'm going to figure out what permissions are needed next but I haven't changed anything since this last worked other than an upgrade to 1.3...
    • Edited by SteelCityIt Wednesday, December 01, 2010 3:57 AM Sorry bad formatting...
    • Proposed as answer by Abstract Labs Wednesday, December 01, 2010 4:00 AM
    Wednesday, December 01, 2010 3:56 AM
  • Interesting observation I have been getting the same error and could not figure out why it was occurring. Turns out I use a source control program that shall remain nameless that marks the file read-only when checked in. If I check out the web.config file it goes away, I have also noticed that when debugging begins the web.config file shows that it was modified and prompts to reload even though nothing changes. It would seem that there is a call in the WaIISHost is trying to call back via a wcf channel and manipulate the file.
    Wednesday, December 01, 2010 4:05 AM
  • I had to modify the permissions and add read access to the USERS group to get past the permission problem. Now my app is almost starting.  I now receive this error:

    System.IO.FileLoadException was unhandled
     Message=Could not load file or assembly 'Microsoft.WindowsAzure.StorageClient, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
     Source=MultiTenantCore
     FileName=Microsoft.WindowsAzure.StorageClient, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
     FusionLog==== Pre-bind state information ===
    LOG: User = NT AUTHORITY\NETWORK SERVICE
    LOG: DisplayName = Microsoft.WindowsAzure.StorageClient, Version=1.0.0.0, Culture=neutral, \
    It's referencing the 1.0.0.0 version of the storage client.  Everything builds ok like this but at runtime I get the exception above.  Do we need to manually change this to use a 1.3 version since the sdk changed?  I'm surprised I'm having so many problems with the upgrade...
    Wednesday, December 01, 2010 4:26 AM
  • The StorageClient assembly in SDK 1.3 is now 1.1.0.0.
    Wednesday, December 01, 2010 4:49 AM
  • Thanks for some reason my project was still pointing to 1.0.0.0.  My project is attempting to start now but I'm getting the InvalidOperationException: SetConfigurationSettingPublisher needs to be called before FromConfigurationSetting can be used exception now.  I've made no changes other than upgrading and troubleshooting the upgrade so I'm at a loss.  I'm doing the typical SetConfigurationSettingPublisher in my WebRole OnStart and everything worked.  This is a pretty big app that I've spent hundreds of hours on..  I can only think of 2 things:

    1) My startup settings are wrong

    2) There are still 1.0.0.0 references that I see when the project is starting up.  ('WaIISHost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\assembly\GAC_MSIL\Microsoft.WindowsAzure.ServiceRuntime\1.0.0.0__31bf3856ad364e35\Microsoft.WindowsAzure.ServiceRuntime.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.) is just 1 example.

    I'm not sure what to do next...

    Wednesday, December 01, 2010 4:57 AM
  • See this thread http://social.msdn.microsoft.com/Forums/en-US/windowsazuredevelopment/thread/ab6d56dc-154d-4aba-8bde-2b7f7df121c1.

    But basically, when you run your web role in full IIS mode, you need to move the call to SetConfigurationSettingPublisher from OnStart to Application_Start (in Global.asax).

    • Proposed as answer by SteelCityIt Wednesday, December 01, 2010 5:27 AM
    Wednesday, December 01, 2010 5:15 AM
  • Fernando you are a genius!  Thank you for your help this upgrade has driven me crazy all night.  I'm up and running and although I don't completely understand what changed with IIS in this upgrade, I'm ok with that tonight :)  Thank you again!
    Wednesday, December 01, 2010 5:28 AM
  • I don't completely understand what changed with IIS in this upgrade

    The change was that a web role now uses full IIS instead of hosted web core.

    Wednesday, December 01, 2010 5:47 AM
  • worked for me!! tx!
    Wednesday, December 01, 2010 7:19 AM
  • Ok.. Got it. In my case I was using rewrite rules - removing the old rewrite rules from my web.config fixed the issue. So in case you are experiencing the same error: check your web.config for all non-default configurations... You got a chance to find some issue there.
    • Proposed as answer by Djon K Wednesday, December 01, 2010 6:10 PM
    Wednesday, December 01, 2010 6:05 PM
  • Confirmed.

    Thank you.

    Thursday, December 02, 2010 8:39 PM
  • confirmed this! it's working!! thanks!
    Friday, December 10, 2010 5:47 PM
  • I followed the same steps but its not working i tried to reinstall everything but still same error is coming..

     

    Any sort of help will be appriciated.

    Monday, December 13, 2010 10:01 AM
  • thx :)
    ptz
    Thursday, December 16, 2010 8:25 PM
  • Confirmed! Thanks!

    Works for me..

    Tuesday, December 21, 2010 11:16 AM
  • In my case I observed an interesting pattern. I had the Web.Config writable but still kept on getting this error. Then I tried making every file in the parent folder of my solution writable to see if that helps and it still did not work.

    After investigating it for some time, I realized that it might be due to the fact that my source code was on another hard drive of my laptop. So I copied an already working Azure test project from my primary drive to thi drive and as expected it gave same error. Then I went ahead and copied the original project to my primary drive without changing any permissions and it worked fine.

    I had already verified that even on the secondary drive the folder had full admin privileges so not sure what happened there. Anyways I can reproduce it consistently where I get same error message every time from secondary drive but same solution works from primary.

     

    Thursday, December 30, 2010 7:31 PM
  • Having the web.config checked out is annoying when working with TFS. We have included a powershell script in our post build steps to perform a checkout.

    It makes life a little bit better when working with Azure  1.3. You can read more about it here.

     

    Kind regards,
    Tom de Koning


    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".
    Wednesday, January 12, 2011 5:06 PM
  • Having the web.config checked out is annoying when working with TFS. We have included a powershell script in our post build steps to perform a checkout.

    It makes life a little bit better when working with Azure  1.3. You can read more about it here.

     

    Kind regards,
    Tom de Koning


    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".

    Hi Tom, I wouldn't use a checkout as post-build step, but only set the readonly attribute bit to false. Your checkout Powershell script in TFS could lead to unneccessary checkouts on TFS on the web.config file....

     

    regards

     

    Patrick Peters

    Tuesday, January 18, 2011 7:16 AM