Azure Storage Emulator: A Guide to Local Development and Testing

The Microsoft Azure storage emulator is a tool that emulates different services like Azure Blob, Queue, and Tables for local development and testing. Earlier, it was part of Microsoft Azure SDK, but now Microsoft often recommends using the Azurite emulator. This Azurite is an open-source tool with a free local environment for testing applications.

However, Azure Storage is still best for local development and testing of your application. You can quickly test your application or run your project against your storage services locally without even incurring extra costs or creating an Azure subscription.

With the Azure storage emulator, you will be satisfied with how your application works. Once you have used the emulator, you can start using an Azure storage account in the cloud. To understand how to get started with this emulator and how to develop and test your application, have a look at this brief guide.

How to Get the Storage Emulator?

To start with this software, you can install it using a standalone installer. To use this installer, you must have administrative privileges on your computer, which only runs on Windows. For Linux, you can use the Azurite emulator. However, it is worth noticing that data created on any version of this emulator may not be accessible when using different versions.

If you want data to persist for a long time, always store data in an Azure storage account. The storage emulator depends on its versions of OData libraries. You cannot replace the OData DLLs with other versions as they are unsupported. However, these versions can be used to send requests to the emulator.

How Does the Azure Storage Emulator Work?

The storage emulator uses a local Microsoft SQL server and a local file system to simulate the Azure storage services. By default, this emulator uses a SQL Server 2012 Express LocalDB database. You have the option to choose the configuration of this, either SQL server or LocalDB instance.

However, some differences still exist in the functionality of Storage Emulator or Azure storage services. The emulator has less space for files and has lower security, but the real deal of the testing environment begins with it. Moreover, you should not miss a chance to learn the core concepts of Azure, such as developing solutions and storage emulator usage. To understand these essential concepts, join CCSLA’s certification course AZ-204T00-A: Developing Solutions for Microsoft Azure.

Authenticate with Shared Access Signature (SAS)

Once you installed the tool, you need to authenticate the request against the Azure storage emulator. The request should not be anonymous and should be authenticated with Shared Key authentication or with a Shared access signature (SAS). Authenticate the storage emulator with shared key credentials using:

[AZURE.INCLUDE storage-emulator-connection-string-include]

Authentication with a Shared Access Signature

Azure storage client libraries like the Xamarin library support authentication with only SAS tokens. For this, you need to create a SAS token with the help of an application that supports Shared Key Authentication.

The most straightforward way to generate the SAS token is via Azure PowerShell:

1. First, install the Azure PowerShell and download its latest version.
2. Now, open the Azure PowerShell and run the following command. Replace the following command according to your credentials and requirements. ACCOUNT_NAME and ACCOUNT_KEY== 
3. Now, replace the following with the name of your choice to generate a SAS token. CONTAINER_NAME

This way, you can produce a SAS URI for a new container, which will be valid for one. On this signature, you can get full access to read, write, delete, and list within the container.

How to Start and Initialize the Storage Emulator?

Select the Start button or press the Windows key from the keyboard to start the storage emulator. Now, begin typing the Azure storage emulator and choose the application from the list that appears. When the emulator starts running, you will see an icon at the bottom of the Windows taskbar. This indicates that your emulator has started working, and a command line is ready to process data. You can use this command line window to start or stop the storage emulator or to clear data. It can be used to get the current status of the program and further initialize the emulation process.

If the command line window gets closed and the storage emulator still continues to run, you must follow the above steps to start the storage emulator again. The local storage environment gets initialized the first time you run the emulator. The initialization process creates a database in LocalDB where reserves of HTTP ports are localized for each local storage service. You can find the emulator installed by default in the C:\Program Files (x86)\Microsoft SDKs\Azure\Storage Emulator directory.

Local Development Environment

How you can develop functions on your local computer solely depends on language and tooling preferences.

Here are some storage environments that support local development and testing:

Initialize the Emulator to Use Different SQL Database

The Azure storage emulator command-line tool can be used to initialize the storage emulator to indicate an SQL database instance rather than the LocalDB instance by default. Remember to run the common-line tool with administrative credentials, as it requires them to initialize the back-end database.

Use the following commands to initialize:

1. Select the Start button or Windows key to search the Azure storage emulator. When you open the emulator, a command line will also appear. 
2. In the command prompt window, type the following instance:

3. You can also use the following command to use the default SQL Server in emulator: 

AzureStorageEmulator init /server .\\

4. Or you can use this command to re-initialize the database to the LocalDB default server instance:

 AzureStorageEmulator init /forceCreate

Authenticate Requests by Connecting to the Emulator Account

Now that you have successfully installed and started the Storage Emulator, you can quickly test the code against it—every request you make needs to be authorized so that no anonymous requests are made. Apart from initializing through SAS or shared essential credentials, connect to an emulator account using the shortcut.

It is the easiest way to connect to the emulator directly from your application. You only need to configure a connection string with the file that immediately references the connection between them. This shortcut is equal to the whole connection string from the emulator that specifies the account name, account key, and the emulator’s endpoints for each storage service.

Shortcut string: UseDevelopmentStorage=true

Use the following .NET code snippet to try out a shortcut from a method of connection string. For instance, the BlobContainerClient(String, String) constructor takes a connection string.

Addressing Resources Against Storage Emulator

The Azure storage emulator’s service endpoints differ from those of the Azure storage account. The local computer here does not have any domain name resolution. It only requires the storage emulator endpoints to be in local addresses. When you address a resource in the Azure storage account, you use the following command:

<http|https>://<account-name>.<service-name>.core.windows.net/<resource-path>

Here, the account is part of the hostname, and the resources in this are being addressed as a URI path, which is local.

For example, The URI is a valid address for the blob in the Azure account. Here is how you can change the syntax and add your valid resource:

https://myaccount.blob.core.windows.net/mycontainer/myblob.txt

The local computer does not have a domain name resolution, so the account name becomes a part of the URI path rather than the hostname. Use the following format for addressing resources in the storage emulator: 

http://<local-machine-address>:<port>/<account-name>/<resource-path>

For the users’ reference, the service endpoints are:

• 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>

Addressing the Secondary with RA-GRS

The storage emulator supports RA-GRS or the read access geo-redundancy replication from its 3.1 version. This ensures that the user can access the secondary location easily by appending the secondary with the account name. However, if you want to access the secondary using the storage emulator, you can use the Storage Client Library, available for .NET version 3.2 or later.

Storage Emulator vs. Azure Storage

Storage emulator differs in functionality from Azure storage as it is an emulated environment that runs in a local SQL instance, while Azure utilizes cloud storage for its function.

Some key differences between them are:

• Storage emulators can support a single fixed account with an authentication key, which is well-known on the cloud. 
• One cannot use the storage emulator to support a large group of concurrent clients as this network is not scalable. This is one of the primary limitations of using a storage emulator, and thus, many people prefer Azure storage for its enhanced storage and wide scalability. 
• Storage emulators address resources put to it in a different manner than Azure storage accounts. The primary reason for this difference is the presence of domain name resolution in the cloud, which is not available on a local computer. 
• The storage emulator account is also known to support read access geo-redundancy replication or the RA-GRS, which makes it more effective. All the accounts that are connected with the emulator will have RA- GRS enabled in them, which ensures that there is no lag in the transmission between the secondary and primary replicas. The operations such as Get Queue Service Stats, Get Blob Service Stats and Get Table Service Stats on the secondary account ensure that the value of the LastSyncTime response element is always returned to the Underlying SQL database in the current time and there is no lag in the transfer of values. If you want to access the secondary storage of the emulator, you can use the Storage Client Library for .NET version 3.2 or later.  
• In spite of having so many benefits and features, the storage emulator still does not support the file service and SMB protocol services endpoints, which can be a hindrance for many professionals. 
• However, suppose you are facing an error message – VersionNotSupportedByEmulator with an HTTP status code 400 – Bad Request. In that case, you are using the storage services in a storage version that the emulator does not yet support.

Connecting Azure Storage with SDKs

Azure storage can be directly connected to the Azurite. The only thing that you need to do is authenticate the steps. The authorization can be done with OAuth, Shared Key, SAS, or Shared Access Signatures.

With Azurite, you can have the following benefits in the Azure storage emulator:-

• Azurite accepts the well-known account and the keys accepted by the legacy Azure storage emulator. 
• You can rotate the account keys in a dynamic way as Azurite, by default, refreshes the account keys and names and differentiates them from the environment variable every minute.

Conclusion

Azure storage emulator service is a cost-effective way of making your development process more accurate and efficient. It is a good emulator that works best while testing Queue Storage, Table Storage, and Azure Blob.

However, it has limitations, such as offering limited space, which can be a hurdle with ample storage units, and not providing security as the Azure official tester. If you are using this, you need to compromise in some aspects, but in conclusion, this storage emulator is an excellent way to test software and services locally. If you want to boost your skills and learn more about these codings and cloud-based concepts, you can join CCSLA’s cloud courses, which offer live instructor-based training and one-to-one mentorship.

FAQs