A very nice feature of Azure Web Apps is the ability to link them to a Git repo (or specific branch of a Git repo) and have the content of the site automatically updated when changes are pushed to that Git repo (or specific branch). I use this feature for the dotnetFlix website and this has been working like a charm for several months.
Today I wanted to make some changes to the site and figured that it would be a good idea to also upgrade to the latest .NET Core version (1.0.1). I switched to the ‘Staging’ branch and started by updating the version-numbers of the dependencies in the project.json file. I made the necessary changes to the content of the site, hit F5 and everything worked like a charm on my local machine.
I pushed the changes to the Staging branch of my Git repo in VSTS and waited for the changes to appear on the Staging website. But when no changes had appeared after waiting a couple of minutes while refreshing the site periodically, I opened the Azure management portal and looked at the deployment status for the Staging website. To my surprise, I was greeted by an exclamation mark to indicate the deployment had failed. The Generate Deployment Script step had failed, but unfortunately the log didn’t reveal any errors.
In my first attempt of finding the root cause of this failure, I compared the Application Settings of the Wep App with one that I created more recently. This proofed to be a golden move because I quickly found a difference. The WEBSITE_NODE_DEFAULT_VERSION setting for the dotnetFlix staging Web App was 0.10.32 and for the new Web App it was 4.4.7.
This could be the problem. After updating the setting to 4.4.7 I did a redeploy and this time everything worked like a charm.
So when you encounter any errors when deploying an Azure Web App, check the WEBSITE_NODE_DEFAULT_VERSION setting and make sure the latest NodeJS version is reflected here.