AZUREMU DOWNLOAD

Azure Storage Emulator: Local Azure Storage Development Tool

Did you search for Azuremu and wonder what could it be? Then, you must be interested in the Azure Storage Emulator that is the tool that Microsoft created for the local storage applications testing. This tool allows developers to mock the Azure Blob, Queue, and Table services in their local Windows environment.

Yet, Microsoft deprecated this tool for quite a time and started recommending Azurite. Let’s learn more about why the emulator is useful and what the differences between the Storage Emulator and Azurite exist.

What Is Azure Storage Emulator

The Azure Storage Emulator is the local development tool that enables developers to simulate the Azure Blob, Queue, and Table storage services. Using this tool, developers will be able to test their applications in their local environment without the need to configure the Azure storage account and spend any money.

The developers will be able to use the Azure Storage Emulator to store their containers, blobs, tables, and queues locally and perform all the testing procedures. Then, once they will be confident in their results, they will be able to connect to an actual Azure storage account and work with the real data.

The main purpose of Storage Emulator is to let the developers copy the Azure storage behavior on their local computer and then finish their work with the real-time data.

Why Was It Useful

The main benefit of Storage Emulator was that it allowed testing without the active Azure subscription. As long as the developer has access to the local instance of the Storage Emulator, they will be able to work on their applications and storage solutions without spending any money on this.

This is especially true for the early stages of development when the working prototype is required. The main benefit of the local storage account is that the developer will be able to work with the concepts and classes that are identical to the ones in the Azure Storage.

The local storage account can also be useful if the developer’s application makes hundreds of calls to the Azure storage. It will be much more efficient to test these calls locally and then connect to the cloud.

Azure Storage Emulator vs Azurite

The most crucial difference between the two tools is that Microsoft officially deprecated the Azure Storage Emulator and now recommends the Azurite.

Azurite is the open source alternative to the Storage Emulator that is used for the development and test purposes. This tool is, in fact, the re-hosted version of the Storage Emulator and is actively maintained for the new features and bug fixes.

Another difference is that Azurite is a cross-platform tool while Storage Emulator only works on Windows. Microsoft recommends that developers use Azurite for development and test in the Linux environment.

Therefore, generally, the Storage Emulator is useful in such a scenario when a developer needs to understand the legacy application or the legacy environment. Otherwise, Azurite is the recommended choice for the modern development environment.

How Does It Work

The Storage Emulator uses a Microsoft SQL Server 2012 Express LocalDB to simulate to the storage services.

Moreover, developers also have the option to update the configuration and connect to the local instance of the SQL database instead of the default LocalDB.

The Storage Emulator can be connected to via the Windows authentication. When the developer runs the Storage Emulator for the first time, it will configure the local environment, create the database in the LocalDB instance, and open several ports for the local services to work.

By default, the Storage Emulator is installed at the following location:

C:\Program Files (x86)\Microsoft SDKs\Azure\Storage Emulator

The Storage Emulator also has the command-line interface which enables all the primary operations, such as the start, stop, initialize, clear, status, and help.

How to Start It

To start the Storage Emulator, the developer should go to the Start Menu, search for the Azure Storage Emulator, and launch the application. Thereafter, there will appear a command window.

When the application is launched for the first time, it will be initialized.

It is important to note that, if another storage emulator, such as Azurite, has been launched, the Storage Emulator will not work properly.

Another option is to launch the emulator from the command prompt. The developers can launch it by running the command:

AzureStorageEmulator.exe start

There are also several additional commands that the developers can use.

For example, to initialize the Storage Emulator with a specific database, the developer should run the command:

AzureStorageEmulator.exe init /server

The initialization process involves several optional commands, such as SkipLocalDB, SkipDatabaseCreation, and SkipPortReservation.

How to Connect Application to the Emulator

The easiest way to connect to the Storage Emulator is via the development storage shortcut:

UseDevelopmentStorage=true

This shortcut refers to the Storage Emulator’s local development account and service endpoints.

The default local endpoint is as follows:

Blob: http://127.0.0.1:10000

Queue: http://127.0.0.1:10001

Table: http://127.0.0.1:10002

A developer can connect their .NET application to the local storage emulator by using the development storage connection string and Azure Storage client library.

The Storage Emulator needs to be running for the application to make requests. The Storage Emulator has the development account called devstoreaccount1 that has a known key. These credentials are only for testing and should never be used in the production environment.

Authentication and Security

The application that uses the Storage Emulator will require the authentication to make requests, unless the request is anonymous.

The Storage Emulator supports the Shared Key authentication, as well as the Shared Access Signatures (SAS). However, the development environment is designed for the local testing and, therefore, does not have the same security features as the production environment.

As a result, the authentication key does not have the same level of security as the actual Azure Storage account. Moreover, the Storage Emulator does not support HTTPS binding, as opposed to the production storage accounts.

The authentication in the Storage Emulator is different since it is a development tool. It is acceptable since the developers typically do not store any production data in the local development environment. However, when the application needs to be transferred to the production environment, it should have the appropriate security features.

What Are the Endpoints

When using the cloud storage account, the host name in the URL address contains the storage account name.

The account name is part of the host since, in the cloud, DNS names are unique and specific for each account. In the Storage Emulator, the account name is a part of the URL path since the local machine does not have a unique domain name.

An example of the local Blob URL address is as follows:

http://127.0.0.1:10000/myaccount/mycontainer/myblob.txt

The three local services (Table, Queue, and Blob) listen on separate ports, namely, 10000, 10001, and 10002.

It is important to develop the applications in such a way that the code can take advantage of the fact that different URLs point to different services.

CLI

The Azure Storage Emulator commands are as follows:

AzureStorageEmulator.exe [start] [stop] [status] [clear] [init] [help]

There are several primary operations, such as start, stop, status, clear, init, and help.

Generally, these commands would be helpful for the developers who want to work with the Storage Emulator in their local environment.

The help command is especially useful since it shows all the commands with descriptions. The graphical interface has been deprecated and, therefore, the command-line interface provides more flexibility.

What Are the Limitations and Differences

The Storage Emulator is not a full-scale production storage account. It has several limitations, such as only supporting one development account. It also cannot support the large-scale applications that need to be hosted in the cloud.

Moreover, the File service and the end of the File service’s SMB mount point are not available in the Storage Emulator. The Storage Emulator will throw an error if a developer tries to use an unsupported version of a message, VersionNotSupportedByEmulator, along with a HTTP 400 error code.

The Blob storage also has several limitations. Namely, the size of a blob is limited to 2 GB, while the name of a blob is limited to 256 characters. Additionally, the Storage Emulator does not support append blobs.

The limitations of the Table Storage are related to the LocalDB. The tables cannot contain more than 1 MB of data, and the limit applies to the row size. The partition and row keys have size limitations and data type restrictions.

Additionally, the range comparisons for Guid and Binary properties are not supported. Moreover, for the SQL environment, the date comparison is limited to the date range supported by the environment.

The Queue Storage does not have any limitations, according to the Microsoft documentation.

What About Data Persistence and Version Compatibility

In general, the Storage Emulator data is only for development purposes, and it is not guaranteed to be compatible across different versions of the emulator. Microsoft recommends that the developers use the actual Azure storage if they need the persistent data.

It is important to understand that the Storage Emulator is a local development tool. Therefore, the data should be treated as something that can be deleted at any time.

Should I Still Use the Azure Storage Emulator

In general, for the Windows-based project that has been using the Storage Emulator, it is critical to understand how the configuration works.

This knowledge will allow the developer to maintain the existing application if there is a need to change anything in the configuration or create the development environment that will replicate the one that their colleagues are using.

On the other hand, when initiating a new project, it is better to choose the Azurite as the modern alternative.

Final Verdict

Azure Storage Emulator has been a useful tool for the developers who need to emulate the storage services in the local environment without spending any money.

Its features, such as the LocalDB instance, local endpoints, authentication, and command-line interface are suitable for the Windows developers that want to test their applications.

Today, the biggest limitation of this tool is the fact that it has been deprecated and is no longer supported.

Therefore, developers should be aware of this tool and understand its features if they are working with the applications or legacy code that utilizes the Storage Emulator.

FAQ