Windows Azure Storage Emulator or Service?

Depending on your development process and what you do on the Windows Azure Platform, today I’m going to announce [again for the very first time] one of the of best kept secrets of the Windows Azure Development when utilizing the Emulator tools.

Secret you say, how secret is it?

It’s such a secret that even the person that originally disclosed this juicy tip doesn’t even remember saying it!


Ryan Dunn originally released this information on Episode 18 of the Cloud Cover Show.

The suspense is killing, what is this about?

Sometimes when using the Storage Emulator while creating a Windows Azure Application you will run into a scenario where you will attempt to read an entity from storage before actually creating on entity of this kind.

This is a problem due to the way the Storage Emulator is structured. The Schema for a particular entity is stored in an instance of SQL Express (by default), because of this, an entity must first be stored to generate the schema before the emulator is aware of what you querying for.

Using this work around will allow you to pre-check to see if the storage account the application is pointing at is the Storage Emulator or the live Storage Service. Once you’ve determined local storage is being used you can create a fake entity save it to Storage (which creates the schema), then promptly delete it before doing your query.

Recently, I worked on a project which used multiple storage accounts for separating data into logical containers. Due to this separation I found myself creating storage connections dynamically. In order to get these accounts to work well locally this trick came in handy.

Enough already, Show us the Codez!

It is a relatively simple fix, it uses the IsLoopBack Property of the Uri class. One slight caveat to this would be if [in the future, or you’ve done some hacking] the Storage Emulator was located on a computer in the local network, as the MSDN documentation describes IsLoopBack as:

A Boolean value that is true if this Uri references the local host; otherwise, false.

But this works great as long as your storage stays local to your dev machine.

Happy Clouding!

Quick Tip: Using Import-Subscription in WAPPSCmdlets 2.2.2

If you find yourself in the position of IT Pro or Dev Ops on the Windows Azure Platform the Windows Azure PowerShell Cmdlets (WAPPSCmdlets) are an invaluable resource to managing services already in the cloud or simply getting your applications deployed.

Recently a new version of the Cmdlets were released offering functionality which will import settings from the publishsettings file [download publishsettings]. To import your Windows Azure Subscriptions for use with the Windows Azure PowerShell Cmdlets run this script:

Import-Subscription D:\PathTo\My.publishsettings

When the Cmdlet has finished executing you’ll notice that the imported subscription has been outputted to the console.

If you’re like me you’ll have access to multiple subscriptions which are reflected in the publishsettings file. However, the Import-Subscription cmdlet only seems to import one subscription (the first one in the file).

To get around this simply comment out the previously imported Subscriptions from the publishsettings file, save, then re-run the Cmdlet.

Happy Clouding!