Table Storage with Azure Portal

To create a storage account, log in to the Windows Azure management portal.  After you log in to the portal you can quickly create a Storage Account by clicking on the large NEW icon at the bottom left hand of the portal. 

From the expanding menu select the ‘Data Services’ option, then ‘Storage’ and finally, ‘Quick Create’.

 

You will now need to provide a name for your storage account in the URL textbox.  This name is used as part of the URL for the service endpoint and so it must be globally unique.  The portal will alert you if you select a name that is already in use.  The next step is for you to select a location for your storage account by choosing one of the data center locations in the dropdown.  This location will be the primary storage location for your data, or more simply, your account will reside in this Data Center.  You may also see an additional dropdown if you have more than one Windows Azure subscription.  This allows you to select the subscription that the account will be related to. 

All storage accounts are stored in triplicate, with transactionally-consistent copies in the primary data center.  In addition to that redundancy, you can also choose to have ‘Geo Replication’ enabled for the storage account. ‘Geo Replication‘ means that the Windows Azure Table data that you place into the account will be replicated in triplicate to another data center within the same region.  So, if you select ‘East US’ for your primary storage location, your account will also have a triplicate copy stored in the West US data center.  This mapping is done automatically by Microsoft and you can’t control the location of your secondary replication, but it will never be outside of a region so you don’t have to worry about your West US based account somehow getting replicated to Europe or Asia as part of the Geo Replication feature.  Storage accounts that have Geo Replication enabled are referred to as geo redundant storage (GRS) and cost slightly more than accounts that do not have it enabled, which are called locally redundant storage (LRS). 

Click ‘Create Storage Account‘ once you have selected the location and provided an account name.  In a few moments the Windows Azure portal will then generate the storage account for you.  When the account is fully created, you will see a status of Online.  By selecting the new storage account in the portal, you can retrieve one of the access keys we will need in order to work with the storage account.

Click on the ‘Manage Access Keys’ at the bottom of the screen to display the storage account name and two 512 bit storage access keys used to authenticate requests to the storage account.  Whoever has these keys will have complete control over your storage account short of deleting the entire account.  They would have the ability to upload BLOBs, modify table data and destroy queues.  These account keys should be treated as a secret in the same way that you would guard passwords or a private encryption key.  Both of these keys are active so that if necessary you can perform a rolling change in configuration for all applications utilizing the accounts in case one of the keys is compromised. 

Your storage account is now created and we have what we need to work with it.  For now, get a copy of the Primary Access Key by clicking on the ‘copy’ icon next to the text box.  Now that we have our storage account set up we can talk about Table Storage.

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