Using the Azure Storage Emulator for Development and Testing
The Windows Azure 儲存體模擬器 provides a local environment that emulates the Azure Blob, Queue, and Table services for development purposes. Using the 儲存體模擬器, 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 download the storage emulator as a standalone package. To configure the 儲存體模擬器, you must have administrative privileges on the computer.|
|Note that data created in one version of the 儲存體模擬器 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 儲存體模擬器.|
Some differences exist between the 儲存體模擬器 and Azure storage services. For more information about these differences, see Differences Between the Storage Emulator and Azure Storage Services.
The 儲存體模擬器 uses a Microsoft® SQL Server™ instance and the local file system to emulate the Azure storage services. By default, the 儲存體模擬器 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 儲存體模擬器 connects to SQL Server or LocalDB using Windows authentication. You can choose to configure the 儲存體模擬器 to access a local instance of SQL Server instead of LocalDB using the Storage Emulator Command-Line Tool Reference.
The 儲存體模擬器 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 儲存體模擬器. They are:
Account name: devstoreaccount1 Account key: Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==
|The authentication key supported by the 儲存體模擬器 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 儲存體模擬器. 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 Windows 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 在計算模擬器中執行 Windows Azure 應用程式.
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 儲存體模擬器, 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 儲存體模擬器 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 儲存體模擬器. 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. For more information, see Registering Custom Domain Names for Blob Resources.|
In the 儲存體模擬器, 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 儲存體模擬器 follows this format:
The following format is used for addressing resources running in the 儲存體模擬器:
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 儲存體模擬器:
|HTTPS is not a permitted protocol for addressing local storage resources.|