Run a Windows Azure Application with the Storage Emulator
Updated: June 7, 2012
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.
Note |
|---|
| To configure the storage emulator, you must have administrative privileges on the computer. |
Important |
|---|
| 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 Windows 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==
Important |
|---|
| 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 Windows Azure Application in the Compute Emulator.
-
Click Start, point to All Programs, click Windows Azure, and then click Emulator.
-
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:
<http|https>://<account-name>.<service-name>.core.windows.net/<resource-path>
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:
http://myaccount.blob.core.windows.net/mycontainer/myblob.txt
Note |
|---|
| 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 Register a Custom Subdomain Name for Accessing Blobs in Windows Azure. |
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:
http://<local-machine-address>:<port>/<account-name>/<resource-path>
The following format is used for addressing resources running in the storage emulator:
-
Blob Service: http://127.0.0.1:10000/<account-name>/<resource-path>
-
Queue Service: http://127.0.0.1:10001/<account-name>/<resource-path>
-
Table Service: http://127.0.0.1:10002/<account-name>/<resource-path>
For example, the following address might be used for accessing a blob in the storage emulator:
http://127.0.0.1:10000/myaccount/mycontainer/myblob.txt
Note |
|---|
| HTTPS is not a permitted protocol for addressing local storage resources. |
See Also
Concepts
Use the Windows Azure SDK Tools to Package, Run, and Deploy an ApplicationUnderstanding Block Blobs and Page Blobs
Understanding the Table Service Data Model
Initialize the Storage Emulator by Using the DSInit Command-Line Tool
Configure SQL Server for the Storage Emulator
Other Resources
Addressing Queue Service Resources
Note
Important