One thing that is a little dicey about the Windows Azure SDK for Node [footnote:“azure” is the name of the associated npm package] 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 default[footnote: I’m sure there’s a way to change that behavior in the IISnode configuration settings] 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);
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 ;)