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 http://windows.azure.com 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 samples.zip in the SDK installation folder,
as well as getting the additional samples from http://code.msdn.microsoft.com/windowsazuresamples. 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.
D:\windowsazure\v1.0\samples\CloudDrive>runme
Starting DevStore
****Starting PowerShell prompt ****
To switch to Blob drive: cd Blob:
To display the contents: dir
...
Name Provider Root
---- -------- ----
Blob BlobDrive http://blob.core.windows.net
Queue QueueDrive http://127.0.0.1:10001
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:\\blob.core.windows.net\
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:\\blob.core.windows.net\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 http://127.0.0.1 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.
