Cloud service web.config gets corrupted after a few days RRS feed

  • Question

  • Hi,

    We are running a web site via Azure CloudService (not the WebSite service).  All works well, we deploy directly from our Visual Studio, and the application seems to run perfectly.

    However, after a site has been deployed, unless we deploy it again within some extended period of time (usually 3-5 days), the websites on the cloud service stops running and IIS starts throwing errors.  If I remote desktop into one of the instances and run it locally to get a more detailed view, I see that all of a sudden the web.config that is running the site is corrupted.  It has an error in it re: asp.net membership and default providers.  Now, I think the error is inconsequential, and in fact, if I remember correctly it is an error that we had once a long time ago.  However, subsequent corrective action in our build and publishing environment fixed it.

    This error seems more like .. if I had to guess... every so often, Azure has to restart our webserver, or re-provision it to another VM and in the process it seems to be using some old cached version of our web.config that is NOT the one we are publishing when we do releases.

    How do I find the errant web.config file and correct it? or prevent Azure from using this incorrect web.config.  Note that when we publish (and we publish using both Azure packaging and WebDeploy, they both work perfectly), we do not have to make any changes to our web.config, it is all managed properly using transformations.




    Friday, May 17, 2013 4:14 PM


All replies

  • Here is what I think is happening in your case...you had your first deployment and that package has this faulty file. Post that, you are using web deploy continuously. What happens as a result is....things work fine...till VM recycles...when VM recycling happens...all the web deploy items are removed and original package is used for re-deployment and corrupt file appears. I suggest you do a fresh deployment without using web deploy option and see if this occurs again.
    • Edited by saransh77 Friday, May 17, 2013 5:21 PM grammer
    Friday, May 17, 2013 5:18 PM
  • Hi,

    So, I did mention that I have tried doing deployments using Web Deploy and then also using "Publish to Windows Azure" (i.e. the one that takes 20 minutes to upload the entire package).

    Neither of them resolve the problem.  Is there a third or different mechanism that I don't know about? maybe I should use the upload package directly from the Azure portal?


    Friday, May 17, 2013 5:37 PM
  • btw, if this is truly whats happening, wouldn't it be considered a bug?  When someone deploys via WebDeploy, the don't expect their public facing applications to be rolled back..


    Saturday, May 18, 2013 12:36 PM
  • The idea behind web deployment is to save time while performing development and testing...it is not for production grade deployments...Microsoft documentation clearly states not to use web deploy option in production.
    Saturday, May 18, 2013 4:59 PM
  • Don't remember ever reading that but thanks for the heads up. I assume we will get this resolved via a new package upload in the control panel. If it doesn't go away I'll be back. Thanks for your help!!


    Saturday, May 18, 2013 5:03 PM
  • Sure...read here...Microsoft Documentation about caution against using web deploy in production environment...http://msdn.microsoft.com/en-us/library/windowsazure/ff683672.aspx
    Saturday, May 18, 2013 5:36 PM