Programming Windows Azure : Using the SDK and Development Storage

10/10/2010 9:53:21 AM
All the storage code you’ve written so far has been code that works directly against the cloud. However, you’ll probably not be developing your applications that way. During the development cycle, it doesn’t make sense to spend money by talking to the cloud on each iteration of the edit-compile-debug cycle. It also makes development a pain from a performance perspective, because you’re always going over the wire to a Microsoft data center. And finally, it blocks development if you don’t have an Internet connection.

You’ll probably spend most of your development time using the tools/code that ships with the SDK, and the cloud storage simulator (creatively called Development Storage) that ships as part of the SDK. In short, the Development Storage (or the Dev Storage) provides most of the features and APIs of the actual cloud services. However, it doesn’t provide the performance or scalability, so you’ll always need to test your final code in the cloud. There are also several minor differences between how features work in the Dev Storage and how they work in the cloud, which could lead to some gnarly debugging sessions if you weren’t aware of them upfront.

Note: Go to to find a link to the SDK download.

1. Installation and Prerequisites

Though installing the actual SDK is fairly straightforward, there are a couple of “gotchas” that you need to keep in mind. Some of this currently isn’t very well documented, and the installer may not check for all the prerequisites.

  • You’ll need .NET 3.5 SP1 installed. The “SP1” part trips up a lot of people because, as of this writing, this was not widely installed. Without this, you will not be able to use ADO.NET Data Services.

  • Ensure that you have a SQL Express instance installed and running with the default instance name. The Dev Storage runs backed by SQL Server and, by default, looks for a SQL Express instance. It is possible to point the Dev Storage to a normal SQL Server instance, but it’s not recommended. Any version of SQL Express should do—either 2005 or 2008.

  • If you plan to use Visual Studio to write code, use Visual Studio 2008 and have the latest service pack installed. As of this writing, that was SP1.

  • Install IIS7 with Windows Communication Foundation (WCF) activation turned on. This is required more for the hosted services part of Windows Azure, but it is good to get all the prerequisites out of the way. This rules out Windows XP as a development platform, because IIS7 works only on Windows Vista/Windows 2003 and later.

  • If possible, try to use a 64-bit operating system and the 64-bit version of the SDKs. This is a purely personal preference, and the 32-bit versions provide the same functionality. You should make your development environment as close as possible to your production environment, so you might try to spend as much time developing on an x64 box as possible.

If you’re like me, you probably install an SDK and then scour through the Start menu to try to find what to launch. However, you should ensure that you unzip in the SDK installation folder, as well as getting the additional samples from This will provide some helpful samples and Cloud Drive, an invaluable tool for debugging and interacting with storage.

2. Using Cloud Drive

Cloud Drive is a useful tool that Windows Azure ships as a part of its extended samples. It is a PowerShell add-in that lets you interact with blob and queue storage (sorry—not table storage) as though they were a locally mounted drive. Don’t worry if you don’t know PowerShell in and out; you can use a minimal set of DOS commands.

Running Cloud Drive is simple. Open a command prompt and run the runme.cmd file in the Cloud Drive folder. It’ll build the Cloud Drive code and mount two “PowerShell providers” corresponding to blob and queue storage, respectively.

Starting DevStore
****Starting PowerShell prompt ****
To switch to Blob drive: cd Blob:
To display the contents: dir

Name Provider Root
---- -------- ----
Blob BlobDrive
Queue QueueDrive

PS D:\windowsazure\v1.0\samples\CloudDrive>

Note: By default, the drives act as a layer on top of the Dev Storage. However, you can easily switch this to point to your actual cloud storage account by modifying MountDrive.ps1 in the scripts directory and switching the $Account, $Key, and $ServiceUrl variables accordingly.

Interacting with the drives is quite simple. Containers are simulated as directories, so you can cd into them as you would with normal folders. The one thing you cannot do is to view contents from directly within the Blob/Queue drive. To do that, you must copy the actual blob/queue message into a filesystem path, and then view it there. Example 1 shows how to switch into the Blob drive and then show a listing of all the containers. It then copies over hello.txt into a local drive for easy viewing.

Example 1. Switching into the Blob drive
PS Blob:\> dir

Parent: CloudDriveSnapin\BlobDrive::http:\\\

Type Size LastWriteTimeUtc Name
---- ---- ---------------- ----
Container 5/9/2009 7:35:00 PM foo
Container 4/19/2009 9:33:36 AM test

PS Blob:\> cd test
PS Blob:\test> dir

Parent: CloudDriveSnapin\BlobDrive::http:\\\test

Type Size LastWriteTimeUtc Name
---- ---- ---------------- ----
Blob 7 5/9/2009 7:21:36 PM hello.txt

PS Blob:\test> copy-cd hello.txt d:\hello.txt

3. Using the Development Storage

The Development Storage (Dev Storage) is a local simulator of the blob, table, and queue storage services. It uses SQL Server to do the actual storing and querying. Hence, you need a SQL Server instance installed and running.

Note: The Dev Storage uses Windows authentication to create a database in your SQL instance. You must ensure that the user account under which you launch the Dev Storage has the right privileges set up on the SQL Server instance.

Running the Dev Storage is quite simple. You can directly launch it from the Start menu, or have it automatically launched by Visual Studio when you press F5 on a cloud project.

By default, it tries to listen on and ports 10000, 10001, and 10002 for blobs, queues, and tables, respectively. If it finds the ports already in use, it’ll grab the next available port.

When using the Dev Storage, there are a few differences that you should be aware of. Though it is very similar to the cloud storage service, there are a few caveats. As always, ensure that you test against the actual cloud before deploying to production.

  • The Dev Storage supports only one account and key (devstoreaccount1 found in the samples). You must use your configuration files and change which account name/credentials you use, depending on whether you’re running in the cloud.

  • You cannot use the Dev Storage for any sort of performance testing. Since the underlying store and implementation are completely different, performance testing against development storage is next to useless.

  • The Dev Storage can be accessed only from the local machine on which it is run. You can work around this by using a port redirector so that multiple developers/computers can get access to a shared instance of the Dev Storage for testing.

  • Sizes and date ranges are different, since the underlying data store is SQL Server. For example, blobs can only be up to 2 GB in the Dev Storage.

  •  Programming Windows Azure : Building a Storage Client
  •  Working with the REST API
  •  Excel Programmer : Fix Misteakes
  •  Excel Programmer : Change Recorded Code
  •  Excel Programmer : Record and Read Code
  •  Configuring Server Roles in Windows 2008 : New Roles in 2008
  •  Windows Server 2003 : Creating and Configuring Application Directory Partitions
  •  Windows Server 2003 : Configuring Forest and Domain Functional Levels
  •  Windows Server 2003 : Installing and Configuring Domain Controllers
  •  Manage Server Core
  •  Configure Server Core Postinstallation
  •  Install Server Core
  •  Determine Your Need for Server Core
  •  Install Windows Server 2008
  •  Windows Server 2008 : Configure NAP
  •  Incorporate Server Core Changes in Windows Server 2008 R2
  •  Decide What Edition of Windows Server 2008 to Install
  •  Perform Other Pre-Installation Tasks
  •  Developing Windows Azure Services that Use SQL Azure
  •  Creating Windows with Mixed Content
    Top 10
    EDGE10 EF240a
    Dell UltraSharp U2412M
    Choosing a... Monitor
    BenQ XL2420T
    Asus PA238Q
    AOC i2352Vh
    Mac Pro - Fully Expandable For High-End Users
    iMac - The Sleekest Desktop PC Ever
    How Much Is Your Data Worth? (Part 2)
    How Much Is Your Data Worth? (Part 1)
    Most View
    Choosing a super-zoom camera (part 2)
    Configuring Networking for Laptops
    Security Fundamentals : Forms Authentication
    iPhone Application Development : Creating a Multi-View Toolbar Application (part 2) - Instantiating the View Controllers
    Choosing a super-zoom camera (part 5)
    Executing Work on a Background Thread with Updates
    Windows Phone 7 Development : Using a WebBrowser Control to Display Dynamic Content
    Mobile Commerce Applications, Part 1
    Parallel Programming : Introducing Parallel Computing
    Microsoft & Apple rejoin the os battle
    SteelSeries Kinzu V2 - Reacquainting With The Kinzu
    2012 - The Year to Come (Part 1)
    HP LaserJet Pro CM1415fnw - Print from The Clouds
    Microsoft XNA Game Studio 3.0 : Text and Computers
    Safeguarding Confidential Data in SharePoint 2010 : Using Active Directory Rights Management Services (AD RMS) for SharePoint Document Libraries
    ASP.NET 4 : Getting More Advanced with the Entity Framework (part 2) - Updates, Inserts, and Deletes
    HP Global Influencer Summit 2012 (Part 2) - HP Photosmart 5520 e All-in-One, HP t410 AIO
    Wireless Networking Essentials (Part 2) : Wireless Repeater, Limitation Of A Wireless Network
    Introducing IBM WebSphere Enterprise Service Bus (WESB)
    Mobile Application Security : The Apple iPhone - Local Data Storage: Files, Permissions, and Encryption