Implementing Storage Que with C# in Azure

Implementing Queue Storage

Queue storage is probably the easiest part to implement. Unlike Table storage, there is no need to setup a model and context, and unlike Blob storage, there is no need to be concerned with blocks and pages. Queue storage is only meant to store small messages, 8 KB or less. Adding a message to a Queue follows the same pattern as the other storage mechanisms. First, get a reference to the Queue, creating it if necessary, then add the message.

Hide   Copy Code

public void Add(CloudQueueMessage msg)
{
    Queue.AddMessage(msg);
}

Retrieving a message from the Queue is just as easy.

Hide   Copy Code

public CloudQueueMessage GetNextMessage()
{
    return Queue.PeekMessage() != null ? Queue.GetMessage() : null;
}

One thing to understand about Azure Queues is they are not like other types of Queues you may be familiar with, such as MSMQ. When a message is retrieved from the Queue, as above, it is not removed from it. The message will remain in the queue however Windows Azure will set a flag marking it as invisible to other requests. If the message has not been deleted from the Queue within a period of time, the default is 30 seconds, it will again be visible to GetMessage calls. This behavior also makes Windows Azure Queues non-FIFO as expected from other implementations.

At some point, you may want get all messages in a Queue. Although the GetMessages method will work for this, however, there are definitely some issues to be aware of. GetMessages takes a parameter specifying the number of messages to return. Specifying a number greater than the number of messages in the Queue will produce andException so you need to know how many messages are in the QUeue to retrieve. Because of the dynamic nature of Queues as explained above, the best Windows Azure can do is give an approximate count though. TheCloudQueue.ApproximateMessageCount property would seem to be perfect for this. Unfortunately though, this property seems to always return null. To get the count, you need to use theQueue.RetrieveApproximateMessageCount() method.

Hide   Copy Code

public static List<CloudQueueMessage> GetAllMessages()
{
    // If the number requested is greater than the actual
    // number of messages in the queue this will fail.
    // So get the approximate number of messages available

    // Although this would seem to a good property to use
    // it will always return null
    //int? count = Queue.ApproximateMessageCount;

    // To get the count use this method
    int count = Queue.RetrieveApproximateMessageCount();

    return Queue.GetMessages(count).ToList();
}

C# Code to Upload Images to BLOB storage account in azure

Using Visual Studio create a new C# Console application.

When the standard console application is created from the template, it will not have a reference to the storage client library. We will add it using the Package Manager (NuGet).

Right-click on the project, and select ‘Manage NuGet Packages’ from the context menu.

This will load up the Package Manager UI. Select the ‘Online‘ tab from the Package Manager dialog, and search for ‘Azure Storage’. As of the time of this writing version 2.0.5.1 was available. Select the Windows Azure Storage package and click ‘Install‘.

If you prefer to manage your packages via the Package Manager Console, you can also type Install-Package WindowsAzure.Storage to achieve the same result. The Package Manager will add the references needed by the storage client library. Some of these references won’t be utilized when just working with BLOB storage. Below you can see that several assembly references were added, but specifically the Microsoft.WindowsAzure.Configuration andMicrosoft.WindowsAzure.Storage assemblies are what we will be working with in this example.

Open up the program.cs file and add the following using statements:

using Microsoft.WindowsAzure.Storage; using Microsoft.WindowsAzure.Storage.Auth; using Microsoft.WindowsAzure.Storage.Blob;

Then add this code to the Main method:

string accountName = "YOUR_ACCOUNT_NAME"; string accountKey = "YOUR_ACCOUNT_KEY"; try {       StorageCredentials creds = new StorageCredentials(accountName, accountKey);     CloudStorageAccount account = new CloudStorageAccount(creds, useHttps: true);       CloudBlobClient client = account.CreateCloudBlobClient();       CloudBlobContainer sampleContainer = client.GetContainerReference("samples");     sampleContainer.CreateIfNotExists();       CloudBlockBlob blob = sampleContainer.GetBlockBlobReference("APictureFile.jpg");     using (Stream file = System.IO.File.OpenRead("MiniAzure.jpg"))     {         blob.UploadFromStream(file);     }                 } catch (Exception ex) {     Console.WriteLine(ex); } Console.WriteLine("Done... press a key to end."); Console.ReadKey();

Modify the code to add the storage account name for the accountName variable and the storage account access key from when you created the account in the portal for the accountKey variable. Also, substitute the file name used with the OpenRead method with a file that you wish to upload. I’d suggest an image or something small for this example.  For real applications, you will want to have the account name and key in a configuration file, or passed in so that you are not hard-coding these values.

The account name and key values are used to create a StorageCredential instance, which is then used to create an instance of the CloudStorageAccount object. The CloudStorageAccount object represents a storage account that you will be accessing. From this object you can obtain references to BLOBs, tables and queues within the storage account. Note that when we create the instance of the CloudStorageAccount, we specify ‘true’ for the useHttps constructor argument. This will cause all of our operation calls to our storage account to be encrypted with SSL. Because all wire-level communications are therefore encrypted, and all requests are signed using the credentials provided in the StorageCredential object, we can have some confidence that our operations are secure from prying eyes.

Since we are using BLOB storage, we then create an instance of a CloudBlobClient object to provide the client interface that is needed to work with BLOBs. Using the CloudBlobClient object we then get a reference to a container. A container is much like a base directory off the root of a hard drive. In this case, the container we are getting a reference to is named “samples”. On the next line, we call CreateIfNotExists which will actually cause the client library to call out to the public REST endpoint in Windows Azure to check if the container exists and, if not, will create the container. This provides us a location to upload our file to.

The last portion of the code gets a reference to a block BLOB within the container we created. This file doesn’t exist yet, we are just creating a reference to it as a CloudBlockBlob object. We will then use this to upload the file by providing a file stream of our file to the UploadFromStream method. The client library will then send up the file, creating the file in our Azure storage account. Note that many of the client library methods support the asynchronous programming pattern using Begin/End versions. For example, to asynchronously start an upload you can call BeginUploadFromStream.  

The client library may make more than one call to the REST API to upload the file if it is fairly large. You can control the size of file that is sent up as a single operation by setting the SingleBlobUploadThresholdInBytes property. This defaults to 32 MB and can be set as high at 64 MB. Anything over that 64 MB mark will be automatically broken into smaller blocks and uploaded. If a file does get broken down by the client library for upload, it will use a single thread by default to perform the upload. You can set theParallelOperationThreadCount property to indicate how many threads you would like the client library to use to concurrently upload your file. Just be sure to be careful that if you are asynchronously uploading a lot of files and setting theParallelOperationThreadCount option fairly high, you may see some ‘bottlenecking’ and slow throughput