5

After deploying to Azure, I kept getting server errors -- the application would not run. So I did a remote desktop into the instance and found that the web.config was completely overhauled...what's going on? I thought web.config was packaged as-is? Instead, the entire configuration has been replaced. When I replace the "new" version with the original, unaltered, correct configuration, my app works as intended.

First off, what's going on here? What am I doing wrong? This way I can understand and not replicate this in the future.

Secondly, how do I stop this behavior? I want the original web.config deployed -- not some arbitrary imposter. Thank you!

dune_buggy
  • 71
  • 5
  • Could you post some examples of the two versions? Do you have Web.config overlays for Debug/Release? Do you have parameter transformations configured? (something like http://msdn.microsoft.com/en-us/library/dd465326%28VS.100%29.aspx ) – Simon Opelt Jun 15 '12 at 12:16
  • Yeah, I tried to post an image of the configs but my "reputation" is too low. I have no overlays or transformations (especially because of this issue). Picture (from same question) is here: http://social.msdn.microsoft.com/Forums/en-US/windowsazuredevelopment/thread/2b5d705e-ffd5-4022-b32d-c67c0fe518cf. – dune_buggy Jun 15 '12 at 12:20
  • could you extract the azure package to verify that the change happens during build/packaging? If you locally build+run the same configurations in the azure emulator the file remains intact? – Simon Opelt Jun 15 '12 at 12:40
  • when extracting the azure package (by unzipping it), I now see that the the file is completely **missing**. Any idea what's going on? – dune_buggy Jun 26 '12 at 05:13

2 Answers2

2

Unless you have a transform specified (using normal, built-in web.config.debug and .release), it doesn't transform any user settings. At one point of time, it did transform the machineKey settings such that your web roles would operate in a web farm scenario (nothing would work behind load balancer if it didn't). I am sure it still does this, but it might be doing it at the machine.config level now (leaving your web.config alone). I haven't checked on this in some time, so not sure what it does now.

Easy way to check what will be deployed is to just package your cskpkg and open up it up as a .zip file. Inside will be another file that has your web role name in it. Open that up as a .zip again and you should see your web site all packaged up. Check the web.config and make sure it is what you need. If not, then post back here what you think shouldn't be changed.

dunnry
  • 6,858
  • 1
  • 20
  • 20
  • Thanks. When I unzip he cskpkg as you suggest, I see that the web.config file is completely **missing** from the 'sites/0' directory. Any idea what's going on here? – dune_buggy Jun 26 '12 at 05:12
  • 2
    Ahhh..found the solution. Using your suggestion as a starting point and realizing the web.config went missing, found this nugget ("Somehow the BuildAction of the web.config file got changed from Content to None.") from [this question](http://stackoverflow.com/questions/9570016/azure-asp-net-mvc-web-config-deployment-issue). Now, deployment is working as expected! Thanks again. – dune_buggy Jun 26 '12 at 05:35
2

Based on dunnry's suggestion to unzip the cskpkg file, I noticed that the web.config was never even packaged -- so Azure must have been creating a basic one out of necessity (without warning me!?!?). After some investigation, I came across this nugget (from another StackOverflow question addressing deployment issues):

Turns out the web.config file wasn't even being included in the deployment package. Somehow the BuildAction of the web.config file got changed from Content to None.

After changing BuildAction back to "Content" my deployment now works as expected.

Community
  • 1
  • 1
dune_buggy
  • 71
  • 5