Hacking .NET and Startups

Managing Your Windows Azure Services from OS X, Linux, or Windows Using the Command Line Interface (CLI)

June 8, 2012 06:14 by Aaronontheweb in Azure, Node // Tags: , , // Comments (4)

A lot of exciting things were announced at today’s Meet Windows Azure event, and one of the things I wanted to share with you is how you can now use our cross-platform Windows Azure Command Line Interface (CLI), part of our Node SDK, to administer your hosted services, VMs, and websites all from the comfort of your favorite terminal.

For the purposes of this blog post I’m going to use iTerm on OS X as my terminal of choice and I’ve also run all of these commands off of the DOS / PowerShell terminals in Windows 7.

Installing the CLI

The Windows Azure CLI is written in Node.JS, so it’s cross-platform by design. To install it you need to have Node.JS and NPM (node package manager) installed.

Once you have both of those, you can just install the CLI using Git and NPM:

$ git clone git://github.com/WindowsAzure/azure-sdk-for-node.git

$ cd ./cli-tools

$ sudo npm install –g

It’s important to do a global install using the –g flag; that way the CLI will always be accessible regardless of what your current working directory is on the terminal.

You can also install the Windows Azure CLI directly via NPM itself:

$ sudo npm install azure -g

Connecting to your Windows Azure Account

With the tools installed, you can now start exploring the SDK. Simply type the following on your terminal to see the full list of commands available in the CLI:

$ azure

In order to effectively leverage any of these, you need to import you Windows Azure account settings and import them into the CLI. You only need to do this once.


This will open up the browser to a page on the Windows Azure portal which will download a .publishSettings file specific to your Azure account automatically. Once it’s downloaded, then you need to import it using the azure account import command.


Once that’s finished, you’re good to go and can start using the CLI to administer your services!


Creating and Managing Windows Azure Websites

Now that we have our account criteria, we can start creating new websites, hosted services, or virtual machines.

If you’re a new Azure customer, you’ll probably want to start with Windows Azure websites – they’re the simplest to set up, cheapest to run, and easiest to deploy.

One small hitch: before you can use the CLI to create Azure websites, you need to create your first one via the new Windows Azure Management Portal. You’ll also need to Git publishing credentials via the web portal too.

I’m going to create a new website by using the azure site create command:


I used the --git flag to tell the Azure web portal “yes, I want to enable Git publishing for this website” which is one of the cool new features.

I can list all of my current Windows Azure websites using the azure site list command – if you have multiple accounts the CLI will list them per-account.


I can also manage my currently running sites, so for instance if I wanted to download my diagnostic logs for a specific site I could run azure site log download and grab the raw data for my performance logs.


You can see a full reference for the Windows Azure CLI here.

Working with Windows Azure VMs

The most sweeping change made in today’s announcements was the inclusion of Windows Azure Virtual Machines; even though it’s still in “preview mode,” you can manage it via the CLI if you have access to the preview (you can apply for Windows Azure Preview Features here.)

I’m going to create a new Linux VM using the CLI.

First thing I want to do is check the list of available VM images, which I can do by running the azure vm image list command.


So you can see the list of default images here – I’m going to use the CentOS image because I’m feeling all Linuxy today.


So I create a new CentOS VM in our US-West data center and I even set up a username and password for administering the box (although I forgot to pass the –-ssh flag, which would add SSH to the box.)

The syntax for creating a new VM is azure vm create <dns-name> <image> <userName> [password].

If I want to check in on the status of this instance, I can just run the azure vm show <name> command to get the details.


Since I don’t want a bunch of people on the Internet hacking into my brand new VM, I’m going to go ahead and delete it via the CLI using the azure vm delete <name>.


Note: when you use --blob-delete command, this deletes the VM’s hard drive image from your storage account permanently.

Working with Hosted Services

You can also manage our signature PaaS offerings on Windows Azure too, our hosted services. I’m already running some of these on my personal Azure account, so I’m going to run the azure service list command to see a list of hosted services:


If I wanted to I could delete hosted services, add new management certificates, and so forth.

Wrapping Up

Our announcements yesterday changed the game with Azure, and using the CLI I now have a level of control and visibility over all of my VMs, websites, and services a mere terminal away from my fingertips. This is a game-changer.

If you need a full reference for the Windows Azure CLI, click here.

If you enjoyed this post, make sure you subscribe to my RSS feed!

How to Build a Real-Time Chat Service with Socket.IO, Express, and the Azure SDK–Part 1: Setting Up

April 16, 2012 13:56 by Aaronontheweb in Azure, Node // Tags: , , , // Comments (0)

This past weekend I ran a Node Bootcamp on behalf of Microsoft and in partnership with the fine folks at Cloud9 IDE – the goal of these camps is to help teach newbies Node.JS and to get some Node.JS-on-Azure business from attendees who have a good experience.

So I decided to build a sample Socket.IO application that leverages our platform and would give our attendees a base to work from when it came time for them to participate in the Node Bootcamp Hackathon. I’ve done a lot of work with Express on Node but had never really done much with Socket.IO, so I was curious to see how hard it was to pick up.

Total time to build and deploy this application from end-to-end, including learning Socket.IO: about 5 hours.

The Requirements

All I wanted to build was a basic chatroom – a simple version of JabbR or something of the sort. Below is a screenshot of the finished product, to give you an idea.


The chat room I wanted had these simple requirements:

  • All currently connected users would be displayed in a list alongside the chat room at all times;
  • Whenever a user connects or disconnects an alert will be displayed to all other members of the chat room and the participant list would be instantly updated;
  • A new user should always be able to see the 30 previous messages in the chat room, including messages from the server;
  • All new messages are always added to the bottom of the list, and the chat window always scrolls down to accommodate any new users;
  • All users are required to have a registered chat handle; and
  • It had to be cross-browser friendly.

These are all pretty simple requirements for a single chat room; nothing too daunting here.

The Tools

So I decided that to pull this off these technologies would make the best fit:


  • Express makes it easy for me to handle custom routes and its session system is the right tool to force users to sign-in with proper user handles before entering the chat room. Express is the primary web framework for Node.JS and I use it in virtually all of my Node projects.
  • cookie-sessions is a Connect Middleware session state provider, and it’s one of the few that doesn’t require an explicit “session store” like a Redis or MongoDB database. Since I was trying to keep this project simple for new Node.JS developers I thought that this NPM package would be the right choice for tracking users’ handles throughout their chat sessions.
  • socket.io is, in my opinion, the industry standard solution for building real-time web applications with WebSockets. I picked socket.io because its ubiquitous, boasts the best cross-browser support out of any real-time app framework, and it plays nice with Express.
  • azure – for my logging requirements, Azure Table Storage made the most sense. I was able to store all of my messages in one table easily and I didn’t have to write much code to leverage it.
  • uuid – used for generating row keys for Azure Table Storage.


  • Foundation CSS – I am an idiot when it comes to CSS; I suck at it and will probably never be very good. Thankfully Foundation is so easy to use that I can fake client-side competence pretty well with it.
  • KnockoutJS – socket.io and Knockout are like chocolate and peanut butter: they were meant to be together. Being able to seamlessly update the chat room’s DOM whenever a new message arrived or a user connected / disconnected made building the front-end tremendously easier.
  • dateformat.js – a popular JavaScript for applying intelligent format strings to timestamps and datetimes; I use this in virtually all of my projects (including ASP.NET MVC.)

The Design

The design of this application is straight forward.

  • Our Express server redirects users who are not cookie’d with a handle already to a sign-in page where they can get one; once they do have a cookie they are sent to the root document which runs the chat server.
  • socket.io handles all of the chat + user events across XHR given that we’re hosting the application inside of IIS, which doesn’t yet support the WebSockets protocol (next version!)
  • Knockout handles the client-side events from socket.io and updates the DOM accordingly.


Next in the series:

Part 2 – Setting up Express and session-handling;

Part 3 – Setting up socket.io

Part 4 – Integrating socket.io on the client-side with KnockoutJS

Part 5 – Using Azure Table Storage for persistent chat

Source Code:

If at any time in this series you want to see the source code to this application, visit my github repo for nodebootcamp-chat here or see it live in action at http://chat.nodebootcamp.com/

If you enjoyed this post, make sure you subscribe to my RSS feed!

How to Use the Azure npm Package Locally without the Azure Compute Emulator

February 6, 2012 05:28 by Aaronontheweb in Azure, Node // Tags: , , , // Comments (2)

One thing that is a little dicey about the Windows Azure SDK for Node 1 is that it by default it depends on being run inside of Azure itself or the compute emulator.

The Azure npm package looks for environment variables parsed from web.config and won’t find them if you run your node application via the node [entrypoint].js commandline.

So why would you want to run your Node application outside the Azure emulator if you’re utilizing the Azure npm package? If you’re using Cloud9 to develop and deploy Node applications to Windows Azure, then that’s one reason.

Another is that IIS eats any error messages your Node application throws by default2 and on some occasions errors don’t always get logged to server.js/logs/[n].txt, so occasionally you have to debug by running the stand-alone node server where you get verbose error messages to console.

To work around this, you can set your tableClient / storageClient / queueClient object to target a specific account directly.

var tableClient = azure.createTableService(ServiceClient.DEVSTORE_STORAGE_ACCOUNT, ServiceClient.DEVSTORE_STORAGE_ACCESS_KEY, ServiceClient.DEVSTORE_TABLE_HOST);

//Live account
var tableClient = azure.createTableService(‘aaronnodedemo’,’scary-looking-access-key’,’ [account].table.core.windows.net’);

When you do this you lose the ability to let Azure .config transforms enable you to switch between production and staging easily, but this can be a necessary evil for debugging tricky bugs ;)

1“azure” is the name of the associated npm package

2I’m sure there’s a way to change that behavior in the IISnode configuration settings

If you enjoyed this post, make sure you subscribe to my RSS feed!

Code Camp Talks: Intro to Node.JS and Building Web Apps with Express

February 2, 2012 17:15 by Aaronontheweb in Node, Azure // Tags: , , , // Comments (0)

This past weekend at SoCal Code Camp I gave two presentations back-to-back on Node.JS: “Intro to Node.JS” and “Building Web Apps with Express.”

I don’t have much to add on what I did at the sessions other than to mention just how surprised I was at how enthusiastic people were to see Microsoft involved with the Node effort and how eager everyone was to learn Node. I was thoroughly impressed.

Below are links to my slides and code samples for both talks – enjoy!

Intro to Node.JS

Source code: Github or Cloud9



Building Web Apps with Express



Let me know if you have any questions!

If you enjoyed this post, make sure you subscribe to my RSS feed!

How to Automatically Utilize Multicore Servers with Node on Windows Azure

January 17, 2012 11:31 by Aaronontheweb in Azure, Azure, Node, Node // Tags: , , , // Comments (0)

One major advantage of developing Node applications for Windows Azure is the ability to have your Node apps managed directly by IIS via iisnode.

You can read more about the benefits of iisnode here, but I want to call out these two points specifically from the iisnode wiki:

Scalability on multi-core servers. Since node.exe is a single threaded process, it only scales to one CPU core. The iisnode module allows creation of multiple node.exe processes per application and load balances the HTTP traffic between them, therefore enabling full utilization of a server’s CPU capacity without requiring additional infrastructure code from an application developer.

Process management. The iisnode module takes care of lifetime management of node.exe processes making it simple to improve overall reliability. You don’t have to implement infrastructure to start, stop, and monitor the processes.

Scalability on multicore servers with Node typically requires developers to use the Node cluster module and write some code which spawns one node.exe process per available processor and write your own handlers for what to do in the event of a failed process and so forth.

Update: It occurred to me after I initially published this that many developers may not understand the need for multiple node.exe processes. If you read through my “Intro to Node.JS for .NET Developers“ you’ll get a better sense for how Node works under the hood – the gist of it is that Node handles all incoming HTTP requests on a single thread, and thus can only utilize a single core at any given time regardless of the number of available processors. Having multiple Node.exe processes handling HTTP requests allows for multiple event loop threads, all of which can be run in parallel across different processors. That’s why this technique is important for multicore systems.

IIS and iisnode can take care of this for you automatically without you having to write any code to do it (a good thing,) and on Windows Azure you can automate this via startup task (fork the source on Github:)

if "%EMULATED%"=="true" exit /b 0

REM Count the total number of available processors on this system
powershell -c "exit [System.Environment]::ProcessorCount"

REM set the default number of processes for our app pools in IIS equal to the 
number of available processors
%windir%\system32\inetsrv\appcmd set config -section:applicationPools 

This startup task automatically determines the number of available processors on the CPU and tells IIS to set the number of worker processes in your Node application pools to use one process-per-core, thus allowing your Node applications to take advantage of every core on the system.

Adding Startup Tasks to Node Projects

If you want to use this startup task in your Node project, follow these steps:


  • The last thing you need to do is just include the startup task in your ServiceDefinition.csdef file, located in the root of your Node Azure Service. The Startup section of the file should look like this:
      <!-- Included by default; installs everything you need to run Node on Azure -->
      <Task commandLine="setup_web.cmd" executionContext="elevated">
          <Variable name="EMULATED">
            <RoleInstanceValue xpath="/RoleEnvironment/Deployment/@emulated" />
      <Task commandLine="setMaxProcessesToAvailableProcessors.cmd" 
          <Variable name="EMULATED">
            <RoleInstanceValue xpath="/RoleEnvironment/Deployment/@emulated" />
    Once all of this is setup, go ahead and deploy your Node service to Azure and it will be able to take advantage of all of the cores on the VMs. The script will dynamically scale with the size of your role instance, so there is no need to alter it.

To verify that the script worked:

  • RDP into one of your Node + Azure instances;
  • Go to IIS Manager from the Windows Menu;
  • Go to Application Pools;
  • Right click on the Application Pool for your Node application and select Advanced Settings – your application pool will be the one that has Applications = 1 on the far right of the table; and lastly
  • Scroll down to Maximum Worker Processes and check the value – in the screenshot below I’m running on a pair of Medium Azure instances, which have two cores each and thus two processes.



And voila, you’re done.

Let me know if you have any questions!

If you enjoyed this post, make sure you subscribe to my RSS feed!

Troubleshooting “500 Internal Server Errors” in the Windows Azure Emulator when Working with Node.JS

January 13, 2012 17:12 by Aaronontheweb in Azure, Node // Tags: , , , // Comments (7)

On my primary development machine, where I have tweaked and prodded IIS multiple times for many projects over the past couple of years, I get the following 500 – Internal Server Error message when I try to fire up even the simplest “Hello World” Node.JS project included in the default template for each Windows Azure Node Web Role:


However, when I push the default “Hello World” Node.JS app to a production on Windows Azure, I have no issues whatsoever! So what’s the problem?


The issue is that the Windows Azure emulator:

  • Creates integrated AppPools for your Node roles in IIS (hosted in iisnode), which is intended for ASP.NET applications that take advantage of the HTTP request processing pipeline in IIS 7+ and
  • Runs the AppPools under an administrative process.

Under these settings, Windows thinks that each Node.exe process is trying to access the integrated IIS pipeline (which only .NET applications can do currently) under the process identity of  the Windows Azure emulator (which has administrative rights), which is not supported. This issue comes up with other CGI / non-.NET applications run in IIS besides Node too.

Here are a few ways to fix the problem:

Fix #1: Set Identity.Impersonation=False in <system.web> in your web.config file

In this instance, simply change the web.config file in the root of your Node.JS application directory to set Identity.Impersonation=False, like this:

	<identity impersonate="false"/>

Effectively this makes it such that your Node role doesn’t not assume the identity of the Windows Azure emulator (which runs in a process with administrative rights), so it runs under a local system process identity and no longer raises the error.

Remember that web.cloud.config affects your live settings on Windows Azure; you want to change just web.config which affects only your local settings when you run in the Windows Azure emulator.

Fix #2: Set validateIntegratedModeConfiguration=False in <system.webServer> in your web.config file

Another alternative is to simply tell IIS to suppress the error altogether, which you can do be editing the system.WebServer section of your web.config file:

<validation validateIntegratedModeConfiguration="false" />

Fix #3: Change the AppPool to Classic Mode

The final and preferred method is to change the AppPool to Classic Mode, which shuts off the application’s access to the integrated IIS processing pipeline regardless of process identity. You can do this via startup task:

%systemroot%\system32\inetsrv\APPCMD.EXE set app "Default Web Site/" /applicationPool:"Classic .NET AppPool"

Although this might be the most kosher method of fixing the issue in IIS, it also happens to be the most awkward to implement on Azure. I’d recommend using approach #1 or #2 instead given that this issue affects the local emulator only.

If you enjoyed this post, make sure you subscribe to my RSS feed!

Node.JS on Windows Azure Part 1: Setting Up Your Environment

January 9, 2012 19:14 by Aaronontheweb in Azure, Node // Tags: , , , // Comments (1)

Following Microsoft’s announcements regarding first-class Node.JS support on Windows Azure, I thought it would be helpful to walk newbie Node.JS and Windows Azure developers through the process of getting their Node.JS development environment set up, building their first simple Node.JS application, and then learning how to take advantage of popular NPM packages like Express to build actual web applications on Windows Azure.

If you need a primer on how Node.JS works and what Node is useful for, go ahead and check out my post from last week: “Intro to Node.JS for .NET Developers.”

Setting Up Your Node.JS + Windows Azure Environment

First, a big disclaimer: all of the Windows Azure deployment and packaging components require Windows in order to work. You will not be able to deploy your application to Windows Azure without a Windows Vista / 7 box.

That being said, the rest of the setup process is straight forward and all of the tools are free (with the exception of one possible text editor I am going to recommend.)

Step 1 – Install the Node.JS Tools for Windows Azure Tools via Web PI

The first thing you need to do is install the Node.JS tools for Windows Azure via Web Platform Installer – click here to install the tools.


This will install:

  • Node.JS for Windows;
  • Node Package Manager (NPM) for Windows; and
  • Windows Azure Powershell for Node.

If you already have a previous version of Node.JS for Windows installed (anything before the latest version, currently v0.6.6), you should uninstall it before running Web PI.

If for whatever reason you need to install Node.JS for Windows manually, you can do it via NodeJS.org.

Once the installation is finished, you should see the following item appear on your Windows bar:


Click on it and you’ll see a PowerShell command window fire up – this command window supports a number of Node + Azure-specific commands you can use for creating new roles and services.


We’ll get around to playing with PowerShell for Node a little later – next we need to set up your Windows Azure account.

Step 2 – Get a Windows Azure Account

In order to take advantage of Node.JS for Windows Azure you’re going to need to have… a Windows Azure account.

If you’re looking for a way to try Windows Azure for free, I recommend signing up for the three-month Windows Azure free trial.

If you’re in a startup and want access to some longer-term Windows Azure benefits, sign up for BizSpark, activate your BizSpark Windows Azure benefits, and get access to some more substantial Windows Azure benefits.

Step 3 – Install a Text Editor with JavaScript Syntax Highlighting

When you step into the world of Node.JS, you’re no longer in a universe where Visual Studio can really help you. Thus, we need to pick up a text editor to use in our Node.JS development.

I recommend that you pick one of the following:

  • Notepad++ – JavaScript syntax highlighting support, lightweight, simple formatting tools, and has a decent number of plug-ins. Cost: free.
  • Sublime Text – this is the community favorite for doing Node.JS; it’s cross-platform so it works on OS X, Linux, and Windows. Cost: free trial, but $59 for a single seat.

Install one of these two text editors and start playing around with it… You’ll get used to it.

Step 4 – Create Your First Node.JS + Azure Project

Now that you have your development environment all set up, now it’s time to create your first Node.JS on Azure project. The official Node.JS for Windows Azure guide will walk you through a lot of the same steps in more detail if you wish to use that instead.

Inside the PowerShell for Node.JS command window, do the following:

  • Create a directory for saving all of  your Node.JS projects – if you want to use “C:\Repositories\Node\” then you can just type mkdir C:\Repositories\Node inside of PowerShell and it will create the directory for you.
  • Change the current working directory to C:\Repositories\Node – type cd C:\Repositories\Node inside the PowerShell window.
  • Create a new Windows Azure service by typing New-AzureService [projectname] – this will automatically create a new [projectname] subdirectory and set it to the current working directory.
  • Create a new Node.JS Web Role (an Azure role that serves HTTP requests from within IIS) by typing Add-AzureNodeWebRole [rolename] – this will automatically create a set of folders under the [projectname]\[rolename] directory which contain everything you need to run your first Node.JS + Azure project.

Here’s what the output looks like in the command window:


Step 5 – Fire Up Your Node.JS Project in the Emulator

Just to make sure that our simple “Hello World” Node.JS project runs properly, we’re going to run it in the emulator before we do anything else with it.

Simply type “Start-AzureEmulator – launch” in the command line, and you’ll see a page like the one below:


Step 6 – Download and Import Your Windows Azure Publication Settings

In order to actually publish to Windows Azure, you have to download your .publishSettings file from the Windows Azure portal. Luckily, you can just do this using the Get-AzurePublishSettings command in the PowerShell window.

This will launch a new web browser window to this page on the Windows Azure portal, which will have you login to your Azure account and will then automatically ask you where you want to save your Windows Azure publication settings.


Save your Windows Azure publication settings to C:\Repositories\Node\[projectname].


Finally, you just need to import your publication settings in the Node.JS PowerShell Window like this:

Import-AzurePublishSettings C:\Repositories\[projectname]\[file-you-downloaded].publishSettings

You should see a message like this in the command window when the operation succeeds:


Step 7 – Publish (and then Take Down) Your “Hello World” Node.JS Project to Windows Azure

The last step before we start diving into Node.JS is getting some experience publishing Node.JS projects to Windows Azure – now that we’ve imported our .publishSettings file we can easily publish our little “Hello World” example directly to the Windows Azure account we set up earlier using the following command in the PowerShell terminal:

Publish-AzureService –name [NewServiceName] –location “North Central US” –launch

This will automatically publish the Windows Azure service in your current working directory (C:\Repositories\Node\[projectname]) to a new hosted service in the North Central United States Azure Data Center called “NewServiceName” with one small instance of the [rolename] Node.JS web role running. The –launch flag will automatically trigger the browser window to open to your service once it finishes deploying.

Here’s what the output window will look like in PowerShell upon a successful deployment:


And you’ll see this in your browser window once the deployment is complete:


If you’re using the Windows Azure free trial or a BizSpark Windows Azure account, you can leave up your Node.JS “Hello World” project if you wish as you’re not going to incur a bill.

However, it’s generally a good practice to take down Windows Azure instances that aren’t doing actual work because in the future you will be billed for the amount of time of the instance is deployed… So to take down an Azure deployment we can either delete it through the Windows Azure management portal or through the following command in the Node.JS PowerShell:


That’s it for this tutorial – the next lesson will show you how to get your hands dirty with the Node Package Manager and Express.JS for doing MVC-style websites in Node!

If you enjoyed this post, make sure you subscribe to my RSS feed!

Intro to Node.JS for .NET Developers

December 14, 2011 04:51 by Aaronontheweb in Azure, Node // Tags: , , , // Comments (7)

Node.js darkMicrosoft announced out-of-the-box support for Node.JS on Windows Azure on Tuesday; we pushed both an official Node.JS SDK for Windows Azure services (table storage, blob storage, and queues) and some tools for creating and managing Node.JS roles on Windows Azure, both of which are available through the official Windows Azure page on Github.

I’ve been playing around with Node for a short while and have the pleasure of working with some great startups that utilize Node heavily in production, so I wanted an opportunity to explain to my fellow .NET developers why they should be excited about Node support on Azure and how they can put it to work for them.

Node at a Glance

If you want to spend 90 minutes and get a full 100-level understanding of Node, check out The Node Beginner Book. If you’re fine with the footnotes, keep reading.

Node is an asynchronous distributed programming platform built on top of Chrome’s V8 JavaScript engine (the same engine used to parse and execute client-side JavaScript inside Chrome.) Node is actually server-side JavaScript, but its syntax and prose are familiar to every web developer to some extent.

Node’s true innovation is its evented + asynchronous I/O model.

var http = require('http');
http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/plain'});
}).listen(1337, "");

The primary method of any Node application runs a single-threaded continuous event loop (the .listen method of the HTTP server), which farms out long-running tasks to worker threads (the anonymous function) which callback the main event loop once they’re finished:

nodejs for dotnet

There are three major advantages to this model:

  • The main event loop uses a single thread to handle multiple concurrent connections, which makes the overhead of Node.JS grow relatively slowly as the number of requests it has to serve increases as there’s no OS thread / process initialization overhead;
  • All long-running tasks (network I/O, data access, etc…) are always executed asynchronously on top of worker threads which return the results via callback to the event loop thread; and
  • JavaScript’s language features (functions as objects, closures, etc…) and Node’s programming model make this type of asynchronous / concurrent programming much easier to utilize – there’s no thread management, no synchronization mechanisms, and no message-passing nonsense. This eliminates a lot of pitfalls that most developers fall into when attempting to develop concurrent applications.

Using Node.JS with .NET

So, you’re a veteran ASP.NET MVC or WCF developer… Why should you be interested in taking a look at Node?

First, Node is fully supported in environments .NET developers are familiar with. Node runs on Windows; Node can be run as a managed module inside of IIS; and Node can now run on Windows Azure. There’s even a NPM package for having Node.JS interop with SQL Server.

Second, Node does a great job tackling vertical issues like real-time notifications, web sockets, and other scenarios that aren’t easily addressed through existing .NET technologies (although SignalR is pretty cool.)

Node isn’t a replacement for everything – frankly, it’s not a great solution for heavy web + database CRUD applications or for serving static content.

Here are some scenarios that I like for Node:

  • Handling multiple concurrent connections (web sockets, handling events from real-time messaging systems [ZeroMQ / Azure Service Bus], anything with socket programming…)
  • High-volume, small response-size systems – think of a real-time logging system where you have to write millions of messages an hour and only send small ACK response objects back to the caller – Node.JS is perfectly suited to handle this;
  • Real-time Pub/Sub systems – if you have an application that is heavy on notifications and needs to do it in real-time, Node is a great choice given its penchant for getting in and out of requests quickly.

Need a pragmatic example?

Take a close look at Socket.IO, arguably the best solution for working with web sockets and long-polling available on any platform.

If you have an application where real-time notifications are important like a messaging application or a social game, then running Socket.IO alongside IIS on your boxes gives you a significantly simplified solution both on the client (the Socket.IO client is backwards compatible all the way to IE5.5) and the server for handling socket connections and routing, and it takes a minimal amount of resource overhead to do it.

I’m going to be doing some more work around Node.JS and Azure in the New Year, so if you have any questions or comments please feel free to hit me up in the comments here.

Want to get started with Node.JS and Windows Azure?

If you want to try out Node.JS on Azure, sign up for the Windows Azure free trial and install the Node.JS Azure SDK via Web Platform Installer.

If you enjoyed this post, make sure you subscribe to my RSS feed!

How to Modify Machine.config on Windows Azure Web Roles

December 1, 2011 19:04 by Aaronontheweb in Azure // Tags: , , // Comments (0)

Earlier this week I spent some time helping a company troubleshoot some performance issues with Windows Azure – their ASP.NET request queue was growing longer than the maximum amount of queued requests supported by default in IIS (5000) during bursts of high activity, so I had to help them find a way to empty the queue faster.

One way to do this is to modify the number of max/min IO and worker threads available to any web role instance, and these values can only be modified through machine.config settings.

As you know, Windows Azure VMs are not persistent so you can’t modify machine.config and save it to file system like how you might if you were hosting IIS on your own local box.

Thus, I crafted a solution using AppCmd and Windows Azure startup tasks.

Here’s some of the code below:

REM Increases the number of available IIS threads for high performance applications REM Uses the recommended values from http://msdn.microsoft.com/en-us/library/ms998549.aspx#scalenetchapt06_topic8 REM Values may be subject to change depending on your needs REM Assumes you're running on two cores (medium instance on Azure) %windir%\system32\inetsrv\appcmd set config /commit:MACHINE -section:processModel -maxWorkerThreads:100 >> log.txt 2>> err.txt %windir%\system32\inetsrv\appcmd set config /commit:MACHINE -section:processModel -minWorkerThreads:50 >> log.txt 2>> err.txt %windir%\system32\inetsrv\appcmd set config /commit:MACHINE -section:processModel -minIoThreads:50 >> log.txt 2>> err.txt %windir%\system32\inetsrv\appcmd set config /commit:MACHINE -section:processModel -maxIoThreads:100 >> log.txt 2>> err.txt

I’ve open-sourced the rest of my IIS machine.config / app pool scripts on Github. Take a look at them and let me know if you have any questions.

If you enjoyed this post, make sure you subscribe to my RSS feed!

How to Migrate Data between On-Premise SQL Server 2008 R2 and SQL Azure Without Getting a Migraine

November 28, 2011 17:33 by Aaronontheweb in Azure, SQL Server // Tags: , , // Comments (2)

I love my job at Microsoft, but there are some times when we simply make it really damn hard for people to do business with us. Migrating data from an on-premise SQL Server to SQL Azure is sadly one of those lapses where, for whatever reason, we’ve left people who aren’t full time SQL Server DBAs totally lost in the wilderness with a set of poorly documented and often dysfunctional tools.

After spending a couple of hours shaving yaks myself tonight trying to move a ~250mb data set (small, but not trivially small) from one SQL Azure database to another, I thought it would be best if I documented what I did to make it work.

Scenario: I needed to download an expensive dataset on one SQL Azure account and migrate it to another on a different SQL Azure subscription, but I needed to make and test some schema changes against the data set locally before I exported it back to its final resting place.

Seems simple enough, right? I just need to:

  1. Download the SQL Azure Database to my local system;
  2. Make a back-up of the dataset locally in case I screw up the other one during my schema changes;
  3. Finish making / testing / integrating schema changes;
  4. Deploy to SQL Azure on new subscription.

Sounds pretty easy to me, as it would any sane developer who’s had some experience working with the Microsoft server stack since 2000.

Rather than tell you the things I spent hours trying that don’t work I’ll explain what does.

Before you do any of this, make sure your SQL Azure Firewall has an exception for whichever development / backup machine you’re using.

Backing Up SQL Azure to On-Premise SQL Server 2008 R2: RedGate’s SQL Azure Backup

SQL Azure Backup from RedGate solved my first problem painlessly – currently SQL Azure Backup is free so grab a copy while you still can.

All you have to do is point it to your target database on SQL Azure and your target on-premise SQL Server database (screenshot taken from RedGate.)

That’s about as complicated as it gets.

Pushing from SQL Server 2008 R2 to SQL Azure: SQL Server Management Studio Data Export (Requires Magic)

One of the SQL Azure migration techniques Microsoft recommends is using the SQL Server Import and Export Wizard to push your data to SQL Azure. Unfortunately they leave one critical part out, which I will show you.

You begin by selecting your database in Management Studio (I’m using the Express edition.)


And for the second step you can leave all of the client / connection settings as-is for your on-premise SQL Server (shown below.)


And now we come to the part that the MSDN documentation totally left out… If you’re like me, you’ll naturally try to login using the SQL Server Native Client 10.0 datasource for your export target, because hey, makes sense right?


As it turns out, you need to use the .NET Framework Data Provider for SqlServer and change the following fields:

  1. Set Security –- Encrypt to true;
  2. Set Security – Password to your SQL Azure login password;
  3. Set Security – User ID to your SQL Azure user id without the @servername at the end;
  4. Set the Source – Data Source property to the servername.database.windows.net – no need to specify any of the TCP or port nonsense here; and finally
  5. Select the Source -- Initial Catalog to be [SQL Azure database you’ve already created on your service but haven’t necessarily set a schema for yet.]

Once you’ve cleared this hurtle it’s pretty much smooth sailing.

If you have any questions about this process or why I didn’t mention some of the available alternatives, go ahead and ask them in the comments and I’ll get back to you.

If you enjoyed this post, make sure you subscribe to my RSS feed!



My name is Aaron, I'm an entrepreneur and a .NET developer who develops web, cloud, and mobile applications.

I left Microsoft recently to start my own company, MarkedUp - we provide analytics for desktop developers, focusing initially on Windows 8 developers.

You can find me on Twitter or on Github!

Recent Comments

Comment RSS

Sign in