FÖRSÄLJNING: 1-800-867-1389
Det här innehållet finns inte tillgängligt på ditt språk men här finns den engelska versionen,

Using the Azure Storage Emulator for Development and Testing

Updated: November 4, 2014

The Microsoft Azure storage emulator provides a local environment that emulates the 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.

The storage emulator is available as part of the Microsoft Azure SDK. You can also install the storage emulator as a standalone package.

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 an Azure storage account, rather than in the storage emulator.

Some differences exist between the storage emulator and 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 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 Storage Emulator Command-Line Tool Reference.

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.

To start the Azure storage emulator, Select the Start button or press the Windows key. Begin typing Windows Azure Storage Emulator, and select Windows Azure Storage Emulator from the list of applications.

Alternatively, if the Azure compute emulator is already running, you can start the storage emulator by right-clicking the system tray icon and selecting Start Storage Emulator For more information about running the compute emulator, see Run an Azure Application in the Compute Emulator.

When the storage emulator starts, a command line will appear. You can use this command line to start and stop the storage emulator as well as clear data, get current status, and initialize the emulator. For more information, see Storage Emulator Command-Line Tool Reference.

When the command line is closed, the storage emulator continues to run. To bring up the command line again, follow the steps above as if starting the storage emulator.

The first time you run the storage emulator, the local storage environment is initialized for you. You can use the storage emulator command-line tool to point to 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. For details, see Storage Emulator Command-Line Tool Reference.

How you address a resource in the Azure storage services differs depending on whether the resource resides in Azure or in the storage emulator services. One URI scheme is used to address a storage resource in 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 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.

In the storage 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.

Beginning with version 3.1, the storage emulator account supports read-access geo-redundant replication (RA-GRS). For storage resources both in the cloud and in the local emulator, you can access the secondary location by appending -secondary to the account name. For example, the following address might be used for accessing a blob using the read-only secondary in the storage emulator:

For programmatic access to the secondary with the storage emulator, use the Storage Client Library for .NET version 3.2 or later. See the Storage Client Library Reference for details.

See Also

Var detta till hjälp?
(1500 tecken kvar)
Tack för dina kommentarer
© 2015 Microsoft