Project description

CarTrackr is a sample application for the ASP.NET MVC framework using the repository pattern and dependency injection using the Unity application block. It was written for various demos in presentations done by Maarten Balliauw.

CarTrackr is an online software application designed to help you understand and track your fuel usage and kilometers driven.

You will have a record on when you filled up on fuel, how many kilometers you got in a given tank, how much you spent and how much liters of fuel you are using per 100 kilometer.

CarTrackr will enable you to improve your fuel economy and save money as well as conserve fuel. Fuel economy and conservation is becoming an important way to control your finances with the current high price.

Source code

Latest version: CarTrackr (ASP.NET MVC 1.0 version)

Author blog feed

 Maarten Balliauw {blog} News Feed 
Tuesday, October 13, 2015  |  From Maarten Balliauw {blog}

Using Azure Web Apps, we can deploy and host Node applications quite easily. But what to do with packages the site depends on? Do we have to upload them manually to Azure Web Apps? Include them in our Git repository? None of that: we just have to make sure our app’s package,json is checked in so that Azure Web Apps can install them during deployment. Let’s see how.

Installing node modules during deployment

In this blog post, we’ll create a simple application using Express. In its simplest form, an Express application will map incoming request paths to a function that generates the response. This makes Express quite interesting to work with: we can return a simple string or delegate work to a full-fledged MVC component if we want to. Here’s the simplest application I could think of, returning “Hello world!” whenever the root URL is requested. We can save it as server.js so we can deploy it later on.


Code highlighting produced by Actipro CodeHighlighter (freeware)

-->var express = require("express");
var app = express();

"/", function(req, res) {
"Hello world!");

"Web application starting...");
"Web application started on port " + process.env.PORT);
<!-- Code inserted with Steve Dunn's Windows Live Writer Code Formatter Plugin. -->

Of course, this will not work as-is. We need to ensure Express (and its dependencies) are installed as well. We can do this using npm, running the following commands:


Code highlighting produced by Actipro CodeHighlighter (freeware)

--># create package.json describing our project
npm init

# install and save express as a dependency
npm install express --save
<!-- Code inserted with Steve Dunn's Windows Live Writer Code Formatter Plugin. -->

That’s pretty much it, running this is as simple as setting the PORT environment variable and running it using node.


Code highlighting produced by Actipro CodeHighlighter (freeware)

-->set PORT=1234
node server.js
<!-- Code inserted with Steve Dunn's Windows Live Writer Code Formatter Plugin. -->

We can now commit our code, excluding the node_modules folder to our Azure Web App git repository. Ideally we create a .gitignore file that excludes this folder for once and for all. Once committed, Azure Web Apps starts a convention-based deployment process. One of the conventions is that for a Node application, all dependencies from package.json are installed. We can see this convention in action from the Azure portal.

Azure Deploy Node.JS

Great! Seems we have to do nothing special to get this to work. Except… What if we are using our own, private npm modules? How can we tell Azure Web Apps to make use of a different npm registry? Let’s see…

Installing private node modules during deployment

When building applications, we may be splitting parts of the application into separate node modules to make the application more componentized, make it easier to develop individual components and so on. We can use a private npm registry to host these components, an example being MyGet. Using a private npm feed we can give our development team access to these components using “good old npm” while not throwing these components out on the public

Imagine we have a module called demo-site-pages which contains some of the views our web application will be hosting. We can add a dependency to this module in our package.json:


Code highlighting produced by Actipro CodeHighlighter (freeware)

"name": "demo-site",
"version": "1.0.0",
"description": "Demo site",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
"author": "",
"dependencies": {
"express": "^4.13.3",
"demo-site-pages": "*"
<!-- Code inserted with Steve Dunn's Windows Live Writer Code Formatter Plugin. -->

Alternatively we could install this package using npm, specifying the registry directly:


Code highlighting produced by Actipro CodeHighlighter (freeware)

-->npm install --save --registry
<!-- Code inserted with Steve Dunn's Windows Live Writer Code Formatter Plugin. -->

But now comes the issue: if we push this out to Azure Web Apps, our private registry is not known!

Generating a .npmrc file to work with a private npm registry in Azure Web Apps

To be able to install node modules from a private npm registry during deployment on Azure Web Apps, we have to ship a .npmrc file with our code. Let’s see how we can do this.

Since our application uses both as well as our private registry, we want to make sure MyGet proxies packages used from during installation. We can enable this from our feed’s Package Sources tab and edit the default package source source. Ensure the Make all upstream packages available in clients option is checked.

Next, register your MyGet NPM feed (or another registry URL). The easiest way to do this is by running the following commands:


Code highlighting produced by Actipro CodeHighlighter (freeware)

-->npm config set registry
npm login
npm config set always
-auth true
<!-- Code inserted with Steve Dunn's Windows Live Writer Code Formatter Plugin. -->

This generates a .npmrc file under our user profile folder. On Windows that would be something like C:\Users\Username\.npmrc. Copy this file into the application’s root folder and open it in an editor. Depending on the version of npm being used, we may have to set the always-auth setting to true:


Code highlighting produced by Actipro CodeHighlighter (freeware)

<!-- Code inserted with Steve Dunn's Windows Live Writer Code Formatter Plugin. -->

If we now commit this file to our git repository, the next deployment on Azure Web Apps will install both packages from, in this case express, as well as packages from our private npm registry.

Installing node module from private npm registry


Thursday, September 17, 2015  |  From Maarten Balliauw {blog}

I have been using Microsoft Azure Cloud Services since PDC 2008 when it was first announced. Ever since, I’ve been a huge fan of “cloud services”, the cattle VMs in the cloud that are stateless. In all those years, I have never seen this error, until yesterday:

There is not enough space on the disk.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.WriteCore(Byte[] buffer, Int32 offset, Int32 count)
at System.IO.BinaryWriter.Write(Byte[] buffer, Int32 index, Int32 count)

Help! Where did that come from! I decided to set up a remote desktop connection to one of my VMs and see if any of the disks were full or near being full. Nope!

Azure temp path full

The stack trace of the exception told me the exception originated from creating a temporary file, so I decided to check all the obvious Windows temp paths which were squeaky clean. The next thing I looked at were quotas: were any disk quotas enabled? No. But there are folder quotas enabled on an Azure Cloud Services Virtual Machine!

Azure temporary folder TEMP TMP quotas 100 MB

The one that has a hard quota of 100 MB caught my eye. The path was C:\Resources\temp\…. Putting one and one together, I deducted that Azure was redirecting my application’s temporary folder to this one. And indeed, a few searches and this was confirmed: cloud services do redirect the temporary folder and limit it with a hard quota. But I needed more temporary space…

Increasing temporary disk space on Azure Cloud Services

Turns out the System.IO namespace has several calls to get the temporary path (for example in Path.GetTempPath()) which all use the Win32 API’s under the hood. For which the docs read:

The GetTempPath function checks for the existence of environment variables in the following order and uses the first path found:

  1. The path specified by the TMP environment variable.
  2. The path specified by the TEMP environment variable.
  3. The path specified by the USERPROFILE environment variable.
  4. The Windows directory.

Fantastic, so all we have to do is create a folder on the VM that has no quota (or larger quota) and set the TMP and/or TEMP environment variables to point to it.

Let’s start with the first step: creating a folder that will serve as the temporary folder on our VM. We can do this from our Visual Studio cloud service project. For each role, we can create a Local Resource that has a given quota (make sure to not exceed the local resource limit for the VM size you are using!)

Create local resource on Azure VM

The next step would be setting the TMP / TEMP environment variables. We can do this by adding the following code into the role’s RoleEntryPoint (pasting full class here for reference):


Code highlighting produced by Actipro CodeHighlighter (freeware)

-->public class WorkerRole : RoleEntryPoint
private const string _customTempPathResource = "CustomTempPath";

private CancellationTokenSource _cancellationTokenSource;

public override bool OnStart()
// Set TEMP path on current role
string customTempPath = RoleEnvironment.GetLocalResource(_customTempPathResource).RootPath;
"TMP", customTempPath);
"TEMP", customTempPath);

return base.OnStart();
<!-- Code inserted with Steve Dunn's Windows Live Writer Code Formatter Plugin. -->

That’s it! A fresh deploy and our temporary files are now stored in a bigger folder.

 Maarten Balliauw {blog} News Feed 

Last edited Oct 15, 2008 at 8:15 AM by maartenba, version 4