Azure SDK for Node.js 0.5.3 is out

We just pushed out a small February update (0.5.3) to the Azure SDK for Node.js, containing the following fixes:

• #81: Start-AzureEmulator errors if there’s a space in the service path: we corrected an issue where the emulator would fail if there was a space in the path to the service
• #82: Remove-AzureService prompts for yes/no confirmation: when you want to remove a service, you will now see this prompt to prevent accidental data loss:

  Confirm
  Are you sure you want to remove service "foo"?
  [Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help
  (default is "Y"):Y
  

• #131: Start-AzureEmulator -Launch fails if run twice on the same web role: corrected a problem where our attempt to clean up logs was causing the emulator to crash
• #138: Publish-AzureService throws ArgumentNullException when no certificates element provided in .cscfg: this may have affected folks using the Mongo commandlets
• #141: Worker role did not allow write access: the user under which Node was running in worker role did not have sufficient permission to write to disk. This may have surfaced as some modules who need to write to disk (such as stylus) failing.

Here is a one-click install of the new bits.

Alongside this, we also released a refresh (0.5.2) of the npm package for Azure, adding support for accessing ServiceBus queues and topics, among other fixes. Read Glenn’s blog post for more details.

Node.js/express blog on Azure in 5 minutes

Following up on the announcements and demos shown at today’s Learn Windows Azure event, I decided to put together a very quick demo that gets you going on Azure with a real app as fast as possible. 

I decided to modify express’ blog sample to use Azure storage, and also pre-configured all the service/role settings that Azure needs so you can get going as fast as possible.

Here is the 5-minute recipe:

1. Get your Windows Azure account
2. Get the Windows Azure SDK for Node.js
3. Get the sample source code from GitHub. If you are wondering where some of the static content in the sample came from, check out this getting started document.
4. Get the needed Node packages by running this inside the ExpressBlog\WebRole folder:
   

   npm install

5. You should now be able to launch the Windows Azure PowerShell for Node.js shortcut from your start menu. Make sure you run as Administrator. The rest of the steps here should be completed from that shell.
6. Download your Azure publish settings:
   

   Get-AzurePublishSettings

7. Import the settings:
   

   Import-AzurePublishSettings mine.publishsettings

8. Head to the Azure portal and create a storage account under your subscription. Make note of the account name and access key.
9. Modify the ExpressBlog\WebRole\Web.cloud.config file where indicated to include the storage settings.
10. You are now ready to publish. Anywhere inside the ExpressBlog folder, run the following, making sure you use a unique service name:
    

    Publish-AzureService -Name uniqueServiceName

You’re all done!

Unfortunately things don’t always go according to plan, so in case you get an Internal Server Error or anything else goes wrong after you deploy to the cloud, use this simple trick to debug.

1. Inside the Web.cloud.config file, enable logging:
   

   <iisnode loggingEnabled="true" />

2. Redeploy the service by simply typing:
   

   Publish-AzureService

3. Look at the Node.js log file for hints of what may be wrong at http://uniqueServiceName.cloudapp.net/server.js.logs/0.txt

Hosting WCF NetTcp services in Azure with a Silverlight client

UPDATE: Folks from the Windows Azure team have posted an improved solution for how to host NetTcp services in Azure by using a WebRole instead of a WorkerRole, which simplifies the setup quite a bit.

Silverlight 4 added support for WCF’s NetTcpBinding, which is a performant and scalable TCP-based binding. It is also a useful binding when used in Windows Azure because it is not affected by Azure’s random load-balancer when using multiple instances of the service and creates an effectively pinned duplex connection to the cloud. The only disadvantage of the NetTcp binding is that it Silverlight does not support TCP transport security, so all the traffic to the web service is unsecured and can be intercepted by malicious parties. That may or may not be acceptable for your application.

I put together a sample on how to host a NetTcp service in Azure and consume it using a Silverlight client. The first thing to keep in mind here, is that Silverlight has some networking restrictions for security reasons. One of this restrictions is that if you want to speak TCP to a server, the server has to expose a policy file over port 80 explicitly listing the ports that it allows TCP for. Moreover, the ports have to be in the range 4502-4530. In other words if my Silverlight app wants to talk to net.tcp://contoso.cloudapp.net:4502, then I need to expose a policy file at http://contoso.cloudapp.net:80. 

Another interesting concern here is that hosting WCF NetTcp services is only allowed in Azure Worker Roles. This is because the Azure Web Role (which is basically an IIS instance) does not have WCF non-HTTP activation enabled.

My sample actually shows two separate approaches on how to implement this. If you already have an external web server where you host static HTML content as well as your Silverlight XAP file, the sample shows an approach using a single Worker Role.

Now if you don’t have an existing webpage, you are probably already considering a Web Role, where you can host the static HTML files and Silverlight XAP file. In that case we can make our life easier by reusing that WebRole to host the clientaccesspolicy.xml file as well. This diagram shows that approach: Web Role + Worker Role.

To run the sample, you need to install the following:

• Visual Studio 2010
• Windows Azure SDK v1.4
• Windows Azure Tools for Microsoft Visual Studio 2010 Platform v1.4

Keep in mind that when you run the sample locally in the development fabric, it will not run correctly, because the the emulator cannot use port 80. Since the policy file has to be hosted on port 80, calls from Silverlight to the service will fail. This gets resolved when you publish the sample to the cloud.

You can get the sample code here.