Node.js Tools for Visual Studio: Deployment Hiccups

Next steps sometimes can be cumbersome. Yesterday, I was trying to deploy a node.js application with express.js to an Azure Website. I was following this tutorial. I figured I’d never make it on first attempt.

Much to my surprise, I did in just six minutes.

On a personal note, I’d like to add that publishing to Azure Websites using git (and getting this really useful deployment history) is something that makes me happy on every single deployment.

So today I was ready for the next step. I am usually working with Visual Studio, so I wanted Node.js Tools for Visual Studio. This give me a lot of benefit out of the box that I’m not even going to mention here, but Scott Hanselman was pretty excited about it some time ago.

So after installing I created a blank Node.js app. To be precise, it was this option.

NodeToolsProject

I was not using any of the Azure variants listed here, as I did not need the deployment scripts they add in this case. For a difference overview of these project types, check out the “Converting to an Azure project type” section on their deployment wiki page.

After the project wizard did it’s job, I created a new commit, created an azure website, added its git endpoint as remote, and pushed. After yesterday’s experience, I figured it would work in about 30 seconds.

Much to my surprise, it didn’t. Not even in six minutes.

Turns out there were two problems.

Problem 1

The project wizard creates a .gitignore file. This seems to be a variation of the standard Visual Studio .gitignore file, which excludes everything beneath bin folders. However, for some reason the project template uses a www file instead of server.js. Guess its path? Right, bin/www. Which means it gets excluded, so I had to make sure to explicitly add it.

Problem 2

Are we good now? Not quite. Contrary to the tutorial I followed yesterday, my “real code” does not live in the root of my git repo. Instead, that’s where the .sln file lives, the project is one level deeper.

| root
| – mynodeapp.sln
| – mynodeapp/
| – mynodeapp.njsproj
| – app.js
| – package.json
| etc …

Which means, Azure will get confused about the nature of your project (won’t recognize it as node.js application) and fail more or less miserably. It just didn’t tell me, as deployment history showed green.

The second last paragraph on this Kudu help site brought me on the right track, as well as a comment on the first tutorial mentioned above: it is necessary to tell Azure website to look one level deeper. The most flexible way of doing so is an app setting entry in the Azure Management Portal itself, under the Configure tab of your website.

The key needs to be Project, and the value has to be <projectfolder>.
Notice the dot at the end. Like so:

NodeWebsiteAppSetting

Saved the settings, headed over to the deployment history and forced a redeploy of my last commit.

And sure enough, it was running as expected.

Hope that helps

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s