Export (0) Print
Expand All
6 out of 10 rated this helpful - Rate this topic

Run a Azure Application with the Storage Emulator

Updated: April 3, 2014

Storage Emulator Guidance: The Windows Azure storage emulator version 2.2.1 is now available as a preview release. This version supports version 2013-08-15 of the Windows Azure storage services. For additional details, see the Windows Azure Storage Team Blog.

Note that the version of the storage emulator that is included with the Windows Azure SDK 2.2 does not support version 2013-08-15. Users attempting to develop against this version of the storage emulator will receive 400 - Bad Request errors.

The Windows Azure storage emulator provides a local environment that emulates the Windows Azure Blob, Queue, and Table services for development purposes. Using the storage emulator, you can test your application against the storage services locally, without incurring any cost.

To configure the storage emulator, you must have administrative privileges on the computer.

Note that data created in one version of the storage emulator is not guaranteed to be accessible when using a different version. If you need to persist your data for the long term, it's recommended that you store that data in a Windows Azure storage account, rather than in the storage emulator.

Some differences exist between the storage emulator and Windows Azure storage services. For more information about these differences, see Differences Between the Storage Emulator and Azure Storage Services.

The storage emulator uses a Microsoft® SQL Server™ instance and the local file system to emulate the Windows Azure storage services. By default, the storage emulator is configured for a database in Microsoft® SQL Server™ 2012 Express LocalDB. You can install SQL Server Management Studio Express to manage your LocalDB installation. The storage emulator connects to SQL Server or LocalDB using Windows authentication. You can choose to configure the storage emulator to access a local instance of SQL Server instead of LocalDB using the DSInit Command-Line Tool.

The storage emulator supports only a single fixed account and a well-known authentication key. This account and key are the only credentials permitted for use with the storage emulator. They are:

Account name: devstoreaccount1
Account key: Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==
The authentication key supported by the storage emulator is intended only for testing the functionality of your client authentication code. It does not serve any security purpose. You cannot use your production storage account and key with the storage emulator. Also note that you should not use the development account with production data.

The first time you run the storage emulator, storage is initialized for you. You can use the DSInit Command-Line Tool to use a different database instance or to reinitialize the existing database. The initialization process creates a database in LocalDB and reserves HTTP ports for each local storage service. This step requires administrative privileges. The tool displays a message indicating that the initialization process has finished.

You can start the storage emulator when you start the Windows Azure compute emulator by using the CSRun Command-Line Tool, or you can start the storage emulator separately by using a menu choice in the Windows Start menu. For more information about running the compute emulator, see Run a Azure Application in the Compute Emulator.

  1. Click Start, point to All Programs, click Windows Azure, and then click Emulator.

  2. Click Storage Emulator.

You can use the user interface of the storage emulator to start, stop, or reset any of the emulated storage services, reset or view the Windows Azure drive folder, or shut down the storage emulator. Resetting a service stops the service, cleans all data for that service from the SQL database (including removing any existing blobs, queues, or tables), and restarts the service. To display the user interface, when the storage emulator is running, right-click the Windows Azure icon in the task bar and then click Show Storage Emulator UI.

When the user interface is closed, the storage emulator continues to run and is available as an icon in the system tray. To shut down the storage emulator, right-click the Windows Azure icon in the taskbar and then click Shutdown Storage Emulator.

How you address a resource in the Windows Azure storage services differs depending on whether the resource resides in Windows Azure or in the storage emulator services. One URI scheme is used to address a storage resource in Windows Azure, and another URI scheme is used to address a storage resource in the storage emulator. The difference is due to the fact that the local computer does not perform domain name resolution. Both URI schemes always include the account name and the address of the resource being requested.

In the URI scheme for addressing storage resources in Windows Azure, the account name is part of the URI host name, and the resource being addressed is part of the URI path. The following basic addressing scheme is used to access storage resources:


The <account-name> is the name of your storage account. The <service-name> is the name of the service being accessed, and the <resource-path> is the path to the resource being requested. The following list shows the URI scheme for each of the storage services:

  • Blob Service: <http|https>://<account-name>.blob.core.windows.net/<resource-path>

  • Queue Service: <http|https>://<account-name>.queue.core.windows.net/<resource-path>

  • Table Service: <http|https>://<account-name>.table.core.windows.net/<resource-path>

For example, the following address might be used for accessing a blob in the cloud:

You can also associate a custom domain name with a storage account in the cloud, and use that custom domain name to address storage resources. For more information, see Registering Custom Domain Names for Blob Resources.

In the compute emulator, because the local computer does not perform domain name resolution, the account name is part of the URI path. The URI scheme for a resource running in the storage emulator follows this format:


The following format is used for addressing resources running in the storage emulator:

  • Blob Service:<account-name>/<resource-path>

  • Queue Service:<account-name>/<resource-path>

  • Table Service:<account-name>/<resource-path>

For example, the following address might be used for accessing a blob in the storage emulator:
HTTPS is not a permitted protocol for addressing local storage resources.

See Also

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
© 2014 Microsoft. All rights reserved.