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

Azure Websites with NuGet Packages From A Custom or Private Feed

Azure Websites offer the capability to deploy from source control, such as Bitbucket or GitHub, instead of you building a deployment package or doing a web publish.

The way that works is that Bitbucket, for example, will send a push notification to your Azure Website whenever a commit is being pushed to it. This will make Azure pull the missing changesets and trigger a build. To make this build possible, it performs a NuGet package restore (if your solution is configured in such a way, that is).

 

This way of deploying has the added benefit of a build service test for your repository: If you’ve forgotten to check in relevant files, your deployment on Azure Websites will fail because the build will break. You don’t get this verification when building a deployment package with files present in your local workspace.

 

While this is a pretty handy and fast way of deploying, it does not work out of the box if you’re using NuGet package feeds that are not accessible for that build service.

There are some possible solutions for that:

  1. Host your NuGet packages in a publicly available location
  2. Direct link these assemblies with copylocal=true instead of using the package structure
  3. Copy them using FTP

You might not want to host your custom packages publicly (1) or circumvent the entire idea of NuGet in the first place just to enable this source code deployment scenario (2)

At Tekaris, we are using custom NuGet packages in a private feed hosted within our own infrastructure, so we chose option 3. Of course, it helps that these packages seldom change.

 

How’s this working? First, go to the management portal at https://manage.windowsazure.com and navigate to your website’s quick start page.

image

Then download the publish profile. Open this file in a text editor and look for FTP host, user and password information.

Use this information to open a FTP connection and navigate to /site/repository/packages

Now simply copy all these missing packages from your local workspace (where they have been used for building your app) to this package directory. Azure will not clean this directory when you do a new commit/deploy, so as long as you don’t need newer versions of them, this is a one-time operation.

 

Hope that helps,

Jonas