The Sheep-Pen of the Shaun

News

Shaun, the author of this blog is a semi-geek, clumsy developer, passionate speaker and incapable architect with about 10 years’ experience in .NET and JavaScript. He hopes to prove that software development is art rather than manufacturing. He's into cloud computing platform and technologies (Windows Azure, Amazon and Aliyun) and right now, Shaun is being attracted by JavaScript (Angular.js and Node.js) and he likes it.

Shaun is working at Worktile Inc. as the chief architect for overall design and develop worktile, a web-based collaboration and task management tool, and lesschat, a real-time communication aggregation tool.

Image Galleries

.NET

May I firstly ask a question for developers writing Node.js application on Windows platform, which editor are you using currently. Being a geeks working with Node.js on Windows for about 1.5 year, I used to use NotePad ++ for the first half a year. Then I switched to use Sublime Text till now on Windows and Mac. I also tried to use WebStorm but give up as I really don’t like its UI, although I knew it’s a powerful tool for web and Node.js development.

Today I was informed that Microsoft publish a new tool that allow us to develop, debug and deploy Node.js application in Visual Studio. And I think this is what’s I’m looking for.

Installation

Node.js Tools for Visual Studio (a.k.a. NTVS) is a free and open source plugin that turns Visual Studio into a Node.js IDE. You can download its first alpha release here. It’s supports Visual Studio 2012 and 2013.

Since this is just a plugin, so we must have Node.js installed on the machine. To download Node.js you can go to its website and click the install button. It will download the proper package based on your system.

Once you have the tool installed you can launch Visual Studio to verify its status. Open the menu item from View >> Other Windows >> Node.js Interactive Window.

Then type the follow command to see the Node.js version installed on your machine.

Node.js Projects, NPM, Editor and IntelliSense

NTVS provides several new project templates for Node.js. When you create a new project, you can find there are six new templates available under JavaScript category.

- From Existing Node.js code

This will brings up a dialog to helps you create a Node.js project from the existing code files.

- Blank Node.js Console Application

Node.js application on console without any modules pre-installed.

- Blank Node.js Web Application

Node.js application that listens on a port by default without any modules pre-installed.

- Blank Express Application

Node.js application with Express module pre-installed.

- Blank Windows Azure Node.js Application

Similar as "Blank Node.js Web Application", with some scripts to prepare Node.js environment when publishing to Windows Azure.

Let's create a very basic Node.js application from the "Blank Node.js Web Application" template. It created three files for us. "server.js" is our application entry code contains some sample code. "README.md" file is a readme file which could be used and displayed if we push to GitHub. "package.json" is the configuration file of this application which contains the name, description, author as well as the dependence modules.

If you are familiar with Node.js application development, you must know NPM. NPM is a Node.js package management program. We can search, install, uninstall any Node.js modules through the NPM command line tool.

NTVS has a build-in NPM management dialog for us to search, install and uninstall NPM modules. In the "Solution Explorer" there's an item named "npm" which contains all modules our application installed. And we can right-click this item and select "Manage npm Modules" to open the NPM dialog.

The NPM Package Management dialog was divided into two parts, installed packages and package sources. To install a new module, we can just specify the package name and optionally its version or tag from the package sources part and click "Install Locally" button, then it will execute relevant NPM command to install the module, and it will update the "package.json" file accordingly so that in the future we can reinstall or update all necessary modules easily.

As the screenshot below I installed "express" module into my Node.js application.

Then in the "Solution Explorer" the "express" module will be shown under the "npm" item. And it will show all sub-dependence modules as well.

The "package.json" file had been updated as well.

NTVS doesn't support install missed modules from "package.json" in this Alpha release. But this feature will be included in Beta as Microsoft mentioned. Currently we can right-click on the project item and select "Open Command Prompt Here" to open the command window, then execute "npm install" command manually to install all missed modules defined in "package.json" file.

Anther feature of NTVS is the Node.js code editor. It's syntax highlight and IntelliSense. When we are typing the code, it will brings the IntelliSense window to us.

And the IntelliSense supports not only those build-in Node.js modules such as "http", but the 3rd party modules we installed from NPM. For example, below is the IntelliSense for "express".

And the functions defined in "express" can also be supported by NTVS IntelliSense.

Debug

NTVS integrates Visual Studio with the "node-inspector" module for Node.js debugging. We can specify a breakpoint in the code editor, hit F5 to execute our application in debug mode. Then it will be paused by our breakpoint where we can step over, step into, watch variants etc.. from Visual Studio in the way we are familiar with.

Windows Azure Support

Another benefit of using NTVS is it supports Windows Azure deployment. We can publish our Node.js project to Windows Azure Web Site by simply click the "Publish" item in the context menu of the project item.

Then in the publish dialog we can create a new Windows Azure Web Site, or specify an existing Windows Azure Web Site for this application, and publish it through Web Deploy or FTP.

But one thing must be pay attention here. If we are using Web Deploy or FTP to publish our Node.js application to Windows Azure Web Site, we MUST include the "node_modules" folder into project to ensure it could be uploaded along with our codes.

But if we are using Git or GitHub integration for Windows Azure deployment, we don't need to include "node_modules" since the Windows Azure Web Site Git deployment command will trigger "npm install" command remotely to install all necessary modules when deployment on the cloud.

Summary

In this post I demonstrated the Node.js Tools for Visual Studio which has just been published its first Alpha release by Microsoft. It brings Node.js IDE into Visual Studio 2012 and 2013 which includes many cool features such as project templates, code editor with syntax highlight and IntelliSense, NPM package management, debugging and profiling, and Windows Azure deployment. With this new tool we can develop and deploy our Node.js application without leaving Visual Studio.

Yesterday when I opened Windows Azure manage portal I found some resources were missed. I checked the website for those missed cloud service and they are still live. Then I checked my billing history but didn't found any problem. When I back to the portal I found that all of those resource are under my MSDN subscription. So I remembered that if this is related with the recently Windows Azure platform update.

This feature named "Enterprise Management", which provides the ability to manage your organization in a directory which is hosted entirely in the cloud, or alternatively kept in sync with an on-premises Windows Server Active Directory solution. By default, all existing windows azure account would have a default Windows Azure Active Directory (a.k.a. WAAD) associated. In the address bar I can find the default login WAAD of my account, which is "microsoft.onmicrosoft.com".

To change the WAAD we can click "subscriptions" on top of the manage portal, select the active directory from the list of "filter by directory" and select the subscription we want to see, then press "apply".

As you can see, the subscription under my MSDN was located in a WAAD named "beijingtelecom.onmicrosoft.com". This is because when Microsoft applied this feature, they will check if you have an existing WAAD in your subscription. If not, it will create a new one, otherwise it will use your WAAD and move your subscription into this directory. Since I created a WAAD for test several months ago, this subscription was moved to this directory.

To change the subscription's directory is simple. First we need to create a new WAAD with the name we preferred. As below I created a new directory named "shaunxu".

Then select "settings" from the left navigation bar, select the subscription we wanted to change and click "edit directory".

You don't have the permission to edit/change directory unless your Microsoft Account is the service administrator of this subscription.

Then in the popup window, select the WAAD you want to change and press "next". All done.

You need to log off and log in the portal then your subscription will be in the directory you wanted. And after these steps I can view my resources in this subscription.

Summary

In this post I described how to change subscriptions into a new directory. With this new feature we can manage our Windows Azure subscription more flexible. But there are something we need keep in mind.

1. Only the service administrator could be able to move subscription.

2. Currently there's no way for us to see our Windows Azure services in more than one directory at the same time. Like me, I can see my services under "shaunxu.onmicrosoft.com" and I must change the filter directory from the "subscriptions" menu to see other services under "microsoft.onmicrosoft.com".

On the 22nd of October Microsoft Announced the new Windows Azure SDK 2.2. It introduced a lot of cool features but one of it shocked most, which is the remote debug support for Windows Azure Cloud Service (a.k.a. WACS).

Live Debug is Nightmare for Cloud Application

When we are developing against public cloud, debug might be the most difficult task, especially after the application had been deployed. In order to minimize the debug effort, Microsoft provided local emulator for cloud service and storage once the Windows Azure platform was announced. By using local emulator developers could be able run their application on local machine with almost the same behavior as running on Windows Azure, and that could be debug easily and quickly. But when we deployed our application to Azure, we have to use log, diagnostic monitor to debug, which is very low efficient.

Visual Studio 2012 introduced a new feature named "anonymous remote debug" which allows any workstation under any user could be able to attach the remote process. This is less secure comparing the authenticated remote debug but much easier and simpler to use. Now in Windows Azure SDK 2.2, we could be able to attach our application from our local machine to Windows Azure, and it's very easy.

How to Use Remote Debugger

Then right click on the cloud project and select "publish". In the publish dialog we need to make sure the application will be built in debug mode, since .NET assembly cannot be debugged in release mode.

I enabled Remote Desktop as I will log into the virtual machine later in this post. It's NOT necessary for remote debug.

And selected "advanced settings" tab, make sure we checked "Enable Remote Debugger for all roles". In WACS, a cloud service could be able to have one or more roles and each role could be able to have one or more instances. The remote debugger will be enabled for all roles and all instances if we checked. Currently there's no way for us to specify which role(s) and which instance(s) to enable.

Finally click "publish" button. In the windows azure activity window in Visual Studio we can find some information about remote debugger.

To attache remote process would be easy. Open the "server explorer" window in Visual Studio and expand "cloud services" node, find the cloud service, role and instance we had just published and wanted to debug, right click on the instance and select "attach debugger".

Then after a while (it's based on how fast our Internet connect to Windows Azure Data Center) the Visual Studio will be switched to debug mode. Let's add a breakpoint in the default web page's form load function and refresh the page in browser to see what's happen.

We can see that the our application was stopped at the breakpoint. The call stack, watch features are all available to use. Now let's hit F5 to continue the step, then back to the browser we will find the page was rendered successfully.

What Under the Hood

Remote debugger is a WACS plugin. When we checked the "enable remote debugger" in the publish dialog, Visual Studio will add two cloud configuration settings in the CSCFG file. Since they were appended when deployment, we cannot find in our project's CSCFG file. But if we opened the publish package we could find as below.

At the same time, Visual Studio will generate a certificate and included into the package for remote debugger. If we went to the azure management portal we will find there will a certificate under our application which was created, uploaded by remote debugger plugin.

Since I enabled Remote Desktop there will be two certificates in the screenshot below. The other one is for remote debugger.

When our application was deployed, windows azure system will open related ports for remote debugger. As below you can see there are two new ports opened on my application.

Finally, in our WACS virtual machine, windows azure system will copy the remote debug component based on which version of Visual Studio we are using and start. Our application then can be debugged remotely through the visual studio remote debugger. Below is the task manager on the virtual machine of my WACS application.

Summary

In this post I demonstrated one of the feature introduced in Windows Azure SDK 2.2, which is Remote Debugger. It allows us to attach our application from local machine to windows azure virtual machine once it had been deployed.

Remote debugger is powerful and easy to use, but it brings more security risk. And since it's only available for debug build this means the performance will be worse than release build. Hence we should only use this feature for staging test and bug fix (publish our beta version to azure staging slot), rather than for production.