TL;DR: This is how to tell Azure to host your node.js web service even though your repository contains .NET solution files and/or projects: Create an app setting called
Project and set its value to the directory where your node app resides, e.g.
src\Server – this is the argument that will make Azure decide to host your node.js stuff and not the .NET stuff.
This is not new – it’s how you pick a .NET project to host as well when your repository contains multiple hostable .NET projects, but when it’s .NET you point to a project file instead of a directory.
Do NOT be fooled by GitHub issues mentioning setting the
SCM_SCRIPT_GENERATOR_ARGS app setting to
--node – doing that will not work together with the
I wrote this blog post because it took me quite a while to figure this seemingly obvious thing out, mostly because I got fooled by various red herrings around the net referring to the aforementioned Kudu setting.
Lately, I’ve been tinkering a bit with Xamarin Studio, trying to get a little bit into building a simple iPhone app.
My app needs a backend, which will be function as a mediator between the iPhone app and another backend, allowing me to
- tailor the service to my iPhone app, trimming the API for my needs, and
- not worry too much about having to update the iPhone app everytime something changes on the real backend (the “backend-backend”…)
But – alas – when I Git-deployed my Azure web site, I got the following message in the Azure portal:
and clicking the log revealed that Azure was kind of confused by the fact that my repository did not contain an obvious single candidate for something to build & deploy – it had multiple (the Xamarin solution
Client.sln and my initial Web API-based dummy server solution
When a Git-deployed Azure web site has multiple things that can potentially be built & deployed, you’ll usually create a
Project app setting and point it to the web project that you want to host in that particular web site, e.g. setting it to
src\Something.Web\Something.Web.csproj if that is a web site.
That’s also what we need to do here! – just by pointing to the directory where your node app’s
package.json resides – in this case it’s
src\Server2 (which was the most awesomest name I could come up with for my server no. 2….) It’s that simple