Author: Jim Nakashima

Overview

The Windows Azure SDK includes two utilities to enable the development of Windows Azure Cloud Services on a local development machine, the Development Fabric and Development Storage.

The Development Fabric simulates the Windows Azure fabric on your local machine so that you may run and test your service locally before deploying it.

Development Storage is a utility that simulates the Blob, Queue, and Table Storage services available in the cloud.

Both the Development Fabric and the Development Storage can be started from shortcuts installed to the start menu or from the Microsoft Service Hosting SDK Command Line. 

That said, the most common usage of these services will be through the integration that the Windows Azure Tools for Microsoft Visual Studio provide. 

This document covers how the tools start and stop the Development Fabric and Development Storage services.

Development Fabric Integration

If the Development Fabric is not already running, it will be started by Visual Studio when you run (ctrl+F5) or debug (F5) a Cloud Service project.

You can see if the Development Fabric is running by looking in your system tray.

You can use the system tray icon to show the Development Fabric UI which allows you to control your role instance (run, suspend, restart and remove) and see log messages.

Below is the Development Fabric running a Service Deployment called “deployment(13)”.

When debugging (F5), the VS Tools will run your Service Deployment and when you stop debugging (includes when you close the instance of IE that VS opened) the Service Deployment will be stopped and deleted from the Development Fabric.

When running, (ctrl+F5), the lifetime of the Service Deployment is managed by the developer.  The deployment will not stop until you go to the Development Fabric UI, select the Service Deployment, stop and/or delete it.

Development Storage Integration

By default, the Windows Azure Tools for Microsoft Visual Studio will also ensure the Development Storage process is running when you run or debug your Cloud Service. 

In order to run or debug your Cloud Service on the Development Fabric without having Visual Studio startup the Development Storage service, set the “Start Development Storage Services” Cloud Service project setting to “False”.

This document is written with the assumption that the “Start Development Storage Services” setting is set to “True”.

The first time the Development Storage service is started up on a given machine, an initialization takes place that can be quite lengthy.  The progress is tracked in the following dialog:

This is not required in subsequent runs.

Blob and Queue Storage Service Integration

When your Cloud Service uses Blob and/or Queue storage but does not use Table Storage (please see the section below on Table Storage Service Integration for more details), the Development Storage service is started up if it is not running already when you run (ctrl+F5) or debug (F5) your Cloud Service.

You can use the Development Storage tray icon context menu to show the Development Storage UI if you want to selectively stop/start/reset services.

Clicking on “Show Development Storage UI” will bring up the following dialog:

The Development Storage service will continue to run until you use the system tray to “Shutdown Development Storage Services”.  That is, across debugging or running Cloud Services, the Development Storage will always continue to run.

Table Storage Service Integration

When using the Table Storage service in your Cloud Service with the Windows Azure Storage services, the tables are created programmatically.  This isn’t true when running against the local Development Storage table service.

The local table storage service needs to run with a database that has the set of tables that corresponds to the project you are running.  The database that the Table Storage service is using is in brackets next to the Table service entry in the Development Storage UI:

These tables need to be created in the SQL Express database that the local Development Storage uses for its storage.  The tables need to correspond exactly to the runtime code.  This is due to a current limitation in the local Development Storage.

Visual Studio will ensure the table storage service is running and using the database that corresponds to your Cloud Service project on run (CTRL+F5) and debug (F5).    

Visual Studio determines which database to from the project settings for the Cloud Service:

When the Database Name is filled out, on run or debug Visual Studio will ensure the Table Storage Service is running with the database specified in this project setting. 

The most common way the Database name project property is filled out is to right click on the Cloud Service node in Solution Explorer and select “Create test storage tables”.

This will run the Windows Azure SDK devtablegen tool over the Role assemblies, create the tables and database, and fill out the project property. 

The database name that Visual Studio uses to populate that project property is the name of the solution.  You can set this property manually which will cause “Create Test Storage Tables” and run and debug will use that database name.

If the property is empty, the table storage service will run with the last database used.  If this is the first time running the storage services, the table storage service will not start. (blob and queue will start)

Note: The Table Service can only run against one database at a time.