Tip of the Day

Really getting the latest changes with TFS

TFS Source Control doesn’t always get the latest changes. It gets what it thinks are the latest changes (and for the most part it gets it right if you work exclusively in Visual Studio). However, there are times when it gets it wrong and you have to force its hand a little.

So, if you have issues getting latest code then what you need to do is:

  • Right click the branch or folder that is problematic
  • Go to the “advanced” sub-menu and click “Get Specific Version…”
  • Then in the dialog check the two “overwrite…” boxes
  • Finally, press “Get”

At this point VS/TFS will retrieve all the files in the branch/folder selected and overwrite existing files. It will also retrieve files it didn’t already have, even although it thought it had them.

Tip of the Day

How to recover deleted files, folders and branches in TFS

In Visual Studio go to the menu item Tools–>Options…

Then navigate to the Source Control –> Visual Studio Team Foundation Server section.

In that section is a check box that says “Show deleted items in the Source Control Explorer”

Once you’ve ensured that the checkbox is checked, press “OK”

Then navigate to the Source Control Explorer and you’ll see that deleted files, folders and branches are now displayed with a large red cross next to them.

Right click the item you want to recover and select “Undelete” from the menu.

At this point Visual Studio stops responding to input. It displays a wait spinner briefly, but mostly it just looks like it has hung.

When Visual Studio does come back to life you can go to the Pending Changes to see the newly recovered files, folders, or branches.

If you are happy with this change, you can check it in to TFS as normal.

Node.js Talk, Talk Examples

DunDDD 2014: Introduction to Node.js–From Hello World to Deploying on Azure

Thank you for those that came to my talk. As promised here are the slides, code, and links given in the talk.

Slides and Code

The slide deck is available as a PDF file.

Links from the talk

Many slides have a link at the bottom, but if you didn’t catch them, here they are again.

Software Development

Deploying a Node.js with Express application on Azure

By the end of the last post, there was enough of an application to deploy it, so let’s deploy it.


  • An FTP client to get at the files on Azure.
  • A GitHub account (or other source control, but this walk through uses GitHub) to deploy to Azure.
  • And an Azure account – this walk through does not require anything beyond the free account.

Setting up Azure

Log in to Azure, then click the "New +" button at the bottom right and Quick Add a website

When that’s okayed a message will appear at the bottom of the page.

Once the website has been provisioned it can be modified. From the starter page or dashboard, source control deployment can be configured

Above the starter page for new websites, below the side bar on the website dashboard.

Then select the desired source control. For this example, the deployment is in GitHub

The choose the repository and branch for the deployment.

Then press the tick icon to confirm.

Once the Azure website and source control are linked, it will start deploying the site…

Once finished the message will change to indicate that it is deployed.


At the point the website can be viewed. However, there are issues with it – It isn’t serving some files, as can be seen here.

What went wrong?

It is rather obvious that something is wrong. Images are not being rendered, although it looks like other things are, such as the CSS.

By examining the diagnostics tools in the browser it looks like the files are simply not found. But, there is no content.

A few blog posts ago, it was noted that if Node.js didn’t know how to handle a route then it would issue a 404 Not Found, but also it would render some content so that the browser had something to display to the user.

Here is a 404 Not Found that gets as far as Node.js:

The the browser window itself is the message that Node.js renders. It is returning a 404 status code, but it has content. Also, note that there is an X-Powered-By: Express as well as the X-Powered-By: ASP.NET from the previous example. This immediately suggests that the 404 is being issued before Node.js gets a chance to deal with the request.

It is for this reason that FTP is required so that some remote administration of the site is possible.

When the site is deployed to Azure, it recognises that it is a Node.js site and will look for an entry point. Normally it looks for a file called server.js, however, it can also work out that app.js is the file it is looking for. So, normally, the entry point into the application should be server.js for installing into Azure.

Azure creates a web.config for the application which has all the settings needed to tell IIS how to deal with the website. However, it is missing some bits. It does not know how to deal with SVG files, so it won’t serve them, even although the Node.js application understands that static content resides in a certain location.

The missing part of the web.config that is needed is:

      <mimeMap fileExtension=".svg" mimeType="image/svg+xml" />


Accessing the files on Azure with FTP

This example uses FileZilla as the FTP Client.

First, the credentials need to be set for accessing the site via FTP. In the Website dashboard, the side bar contains a link to “Reset your deployment credentials”.

When clicked a dialog appears that allows the username and password to be set.

Once this is filled in and the tick clicked, the details for connecting via FTP will be in the side bar on the dashboard.

These details, along with the password previously created, can be used to connect via FTP.

Once connected, navigate to the location of the web.config file, which is in /site/wwwroot and transfer the file to the source code directory. The file can now be edited along with other source code and that means that when it is deployed any relevant updates can be deployed in one action, rather than requiring additional actions with FTP.

The changes to the web.config are to add the following

<mimeMap fileExtension=".svg" mimeType="image/svg+xml" />

to the <configuration><system.webServer> section of the file.

Finally, add the web.config file to the repository, commit the changes to source control and push it to GitHub. It only takes a few moments for Azure to pick it up and then the portal will display a new item in the deployment history.

Refreshing the site in a browser window finally reveals the missing graphics.

The project on GitHub

This was marked as a release on GitHub as part of the Xander.Flashcards project.

Software Development

Node.js with Express – Come to the dark side. We have cookies!

So far, so good. At the point the application displays a list of languages and will display the language that the user picked. However, for the flashcards to work, that selection will have to be remembered. As there is so little state, it is possible to store that in a cookie.

Express handles the creation of cookies without the need for middleware. However, in order to read back the cookies a parser is needed.

Setting and Removing the cookie

To set the cookie with the language that is received from the form on the page:

var language = req.body.language;
var cookieAge = 24*60*60*1000; // 1 day
res.cookie("flashcard-language",language,{maxAge:cookieAge, httpOnly:true});

In the above code, the language is set from the form value, as seen in the previous blog post. The cookieAge is set to be one day, after which it will expire. Finally, the cookie is added to the response object. It is named "flashcard-language".

When the route is requested the HTTP response header will look something like this:

HTTP/1.1 200 OK
X-Powered-By: Express
Set-Cookie: flashcard-language=ca; Max-Age=86400; Path=/; Expires=Mon, 17 Nov 2014 23:22:12 GMT; HttpOnly
Content-Type: text/html; charset=utf-8
Content-Length: 18
Date: Sun, 16 Nov 2014 23:22:12 GMT
Connection: keep-alive

To clear the cookie, call clearCookie and pass in the name of the cookie to clear.


The HTTP Response will then contain the request for the browser to clear the cookie:

HTTP/1.1 304 Not Modified
X-Powered-By: Express
Set-Cookie: flashcard-language=; Path=/; Expires=Thu, 01 Jan 1970 00:00:00 GMT
ETag: W/"SuG3Z498eJmmc04TIciYHQ=="
Date: Sun, 16 Nov 2014 23:29:25 GMT
Connection: keep-alive

Reading in the cookie

In order to read in the cookie some middleware is required. The changes to the app.js file are:

// Requirements section
var cookieParser = require("cookie-parser");
// set up section

And in the route function that responds to the request, the cookie can be read back like this:

var language = req.cookies["flashcard-language"];

Code for this post

The code for this can be found here on GitHub.

Software Development

Node.js with Express – Getting form data

Now that view engines are wired up and working on this application, the next area to look at is getting data back from the browser.

By default Express doesn’t do anything with form data in the request and a piece of “middleware” needs to be added to get this to work. The reason for this is that there are many ways to process data from the browser (or perhaps it is data from something that is not a browser), so it is left up to the developer how best to process that data.

The view now has a form element and a submit button. It also has an input which will contain the name of the language the user wants. This information is transmitted to the server when the user presses the submit button.

In order to read this information a piece of middleware called body-parser is added.

First, it has to be installed into the application:

npm install body-parser --save

Then the application need to know about it. The following changes are made to the app.js file:

// In the requiments section
var bodyParser = require("body-parser");
// In the set up section
// Set up the route as an HTTP POST request.
app.post("/set-language", setLanguage);

Since body-parser can handle a few different types of encoding the application needs to know which to expect. Browsers return form data as application/x-www-form-urlencoded parser, so that’s the parser that is used by the application.

There are some limitations to body-parser but it is good enough for this application. For example, it does not handle multi-part form data.

The route function can now read the body property that body-parser previously populated.

module.exports = function(req, res){
    var language = req.body.language;
    res.send("set-language to "+language);

This will now return a simple message to the user with the language code that was set on the previous page.

Viewing the full source code

Rather than paste the source code at the end of the blog post, I’ve released the project on to GitHub. You can either browse the code there, or get  a copy of the repository for examining yourself. There may be changes coming, so it is best to look for the release that corresponds with this blog post.

Software Development

Express for node.js – View Engines

In the last post, Express Hello World, I talked about getting started with an Express application in Node.js. In it, the output was rendered by writing HTML directly. In most situations that is undesirable and some sort of view or template engine is better suited to rendering the output.

This post follows on directly from that, so any modifications will be based on what the end result was at the end of the last post. The final output from this post will be shown at the bottom.

There are quite a few view engines out there. A popular one for express is jade, but personally I find it too far from HTML to be useful. This is especially true if you work with graphic designers whose tools will output HTML that the developer has to mould into a view for the application to run. The less rework there the better, in my opinion.

So, I’m going to use EJS in this post. It is a bit like the ASPX view engine in .NET applications, but its actually a derivative of Ruby’s ERB.

To install EJS add the "ejs" package to the application.

npm install ejs --save

Configuring the view engine

Express needs to know which view engine is going to be used, it also needs to know where you are going to store the views. So the following lines are needed in the app.js file from the previous post

app.set("view engine","ejs");

Changing the route to render the view in the response

As express has been told to look in a directory called "views" to get the views, the view is going to go into that directory. At this time all that is going into helloworld.ejs is the HTML that was derectly sent form the route in the last post. The helloworld.ejs file now looks like this:

<h1>Hello, World!</h1>

And the route looks like this:

module.exports = function(req, res) {

This will now give the same output as before.

So far, this has done nothing new for us. The power of views is the ability to pass data to them and for them to render it nicely for the user.

Sending data to the view

This is relatively easy. All that needs to happen is that the response.render call needs an additional parameter which contains the information.

module.exports = function(req, res) {

In order to render the information the view has to be changed too.

<h1>Hello, <%= name %>!</h1>

Adding a layout

EJS, out of the box, does not support layouts (or master pages as .NET’s ASPX view engine calls them). However there is a package that can be added that adds layout support. To install:

npm install express-ejs-layouts --save

And the changes in app.js file

// in the requirements section
var ejsLayouts = require("express-ejs-layouts");
// in the set up section

And that’s it. Your application can now use layouts, by default it uses the file layout.ejs in the views folder, but this can be changed if you prefer.

To demonstrate this, here is a layout:

        <title>Express with EJS</title>
        <link rel="stylesheet" href="/css/bootstrap.css"/>
        <link rel="stylesheet" href="/css/bootstrap-theme.css"/>
        <div class="container">
            <%- body %>
        <script type="application/javascript" src="/js/bootstrap.js"></script>

The <%- body %> indicates where the body of the page should go. This is the view that is names in the response.render function call.

Running the application at this point now shows that the view with its layout are now being rendered. But there is a problem. The styles are not showing up correctly.

Accessing static files

By default Express will not serve static files. It needs to be told explicitly where the static files are so that it can render them. While this may seem a little bit of a pain over something like an ASP.NET MVC application, where IIS will server anything in the folder that it recognised (and it recognises a lot), it is actually somewhat comforting that it won’t serve up files by accident.

To set up a folder to be served add the following line to the app.js file:

app.use(express.static(__dirname + '/public'));

What this does is tell Express that a directory called public contains static content and files should be served directly when requested. The __dirname is the directory where the current file is located. So what this means is that public is a directory located in the same directory as the app.js file.

What is interesting here is that the path to the static resource is a full server path. That means the public files can be anywhere on the server, or addressable by the server. The path in the URL will be translated to the full server path as needed. So that means that even although I have a directory called public in my Express application, the browser doesn’t see that directory. It only sees what is in it.

So, from the browser’s perspective the bootstrap.css file is located at /css/bootstrap.css but my application sees it as …/public/css/boostrap.css.


In this post the Hello World application was advanced with the EJS view engine along with layout support and the ability for static files to be rendered to the browser.

The app.js file now looks like this:

// Requirements
var express = require("express");
var http = require("http");
var ejsLayouts = require("express-ejs-layouts");
var hello = require("./routes/hello.js");

// Set up the application
var app = express();
app.set("port", process.env.PORT || 3000);
app.set("view engine","ejs");
app.get("/", hello);

// Run up the server
http.createServer(app).listen(app.get("port"), function(){
    console.log("Express server listening on port " + app.get("port"));

The routes/hello.js file now looks like this:

module.exports = function(req, res) {

The views/layout.ejs file looks like this:

        <title>Express with EJS</title>
        <link rel="stylesheet" href="/css/bootstrap.css"/>
        <link rel="stylesheet" href="/css/bootstrap-theme.css"/>
        <div class="container">
            <%- body %>
        <script type="application/javascript" src="/js/bootstrap.js"></script>

The views/helloworld.ejs file looks like this:

<div class="row">
    <div class="col-md-12">
        <h1>Hello, <%= name %>!</h1>

And twitter bootstrap was installed into the public directory. The project structure now looks like this: