static void TestInvertDictionary(string[] args)
        {
            Dictionary<string, string[]> dict = new Dictionary<string, string[]>();
            dict["0"] = new string[] { "a", "b", "c" };
            dict["1"] = new string[] { "b", "c", "d" };
            dict["2"] = null;
            dict["3"] = new string[] { "x", "y", "z" };
            dict["4"] = new string[] { "s", "i", "d" };
            dict["5"] = new string[] { "p", "o", "o", "j", "a" };            
            foreach (var kvp in dict.Invert())
            {
                Console.Write(kvp.Key + " : ");
                foreach (var item in kvp.Value)
                {
                    Console.Write(item + " , ");
                }
                Console.WriteLine();
            }
            Console.ReadLine();
        }

Yes, it is possible to write a console app that accesses Azure Storage. I encountered several gotcha's in this process. My first attempt to write a console app that uploaded some files to azure resulted in something like this:

using System;

using System.Configuration;

using System.IO;

using Microsoft.WindowsAzure;

using Microsoft.WindowsAzure.StorageClient;

...

var storageAccount = CloudStorageAccount.FromConfigurationSetting("myConnectionString");

CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();

CloudBlobContainer blobContainer = blobClient.GetContainerReference(container);

blobContainer.CreateIfNotExist();                

DirectoryInfo di = new DirectoryInfo(directory);

foreach (FileInfo fi in di.GetFiles(searchPattern))

{

    string name = fi.Name;

    var blob = blobContainer.GetBlobReference(name);

    blob.UploadFile(fi.FullName);                 

    Console.WriteLine("uploaded " + fi.FullName);

}

where myConnectionString is defined in app.config like so:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <connectionStrings>
    <add name="myConnectionString" connectionString="DefaultEndpointsProtocol=http;AccountName=XXX;AccountKey=XXX"/>
  </connectionStrings>  
</configuration>

GOTCHA #1

Running this code gave me following exception:

System.Runtime.InteropServices.SEHException was caught Message=External component has thrown an exception. Source=msshrtmi ErrorCode=-2147467259
StackTrace:
at RoleEnvironmentGetConfigurationSettingValueW(UInt16* , UInt16* , UInt64 , UInt64* )
at Microsoft.WindowsAzure.ServiceRuntime.Internal.InteropRoleManager.GetConfigurationSetting(String name, String& ret)
at Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.GetConfigurationSettingValue(String configurationSettingName)
at AzureUpload.Program.b__2(String configName, Func`2 configSetter) in C:\Users\siddjain\Documents\Visual Studio 2010\Projects\ConsoleAplication1\Program.cs:line 51
at Microsoft.WindowsAzure.CloudStorageAccount.StorageAccountConfigurationSetting..ctor(String configurationSettingName)
at Microsoft.WindowsAzure.CloudStorageAccount.FromConfigurationSetting(String settingName)
at AzureUpload.Program.UploadBlob(String directory, String searchPattern, String

This post explains how to fix it. Azure calls into your code to get the configuration string. Hence, you need to define a method that will return the config string to azure, before you call

CloudStorageAccount.FromConfigurationSetting("myConnectionString")

. The fix was to add following code:

CloudStorageAccount.SetConfigurationSettingPublisher((configName, configSetter) =>
{
   // for a console app, reading from App.config
   configSetter(ConfigurationManager.ConnectionStrings[configName].ConnectionString);
   // OR, if running in the Windows Azure environment
   // configSetter(RoleEnvironment.GetConfigurationSettingValue(configName));
});

Alternatively, use the CloudStorageAccount.Parse method instead of CloudStorageAccount.FromConfigurationSetting.

GOTCHA #2

I was able to upload blobs now, but couldn't access them in IE. Kept getting 404s. To fix this, we need to mark the container as public as in:

if (blobContainer.CreateIfNotExist())
{
    blobContainer.SetPermissions(new BlobContainerPermissions
        { PublicAccess = BlobContainerPublicAccessType.Blob }
    );
}

GOTCHA #3

the '/' character is OK to use in blob name (it gives the illusion of a hierarchy), but not OK to use in container name.

GOTCHA #4

I tried following container name "TestContainer" and got an exception at blobContainer.CreateIfNotExist() with following message: One of the request inputs is out of range. It turns out upper case characters are not permitted in container names. See this post: https://msdn.microsoft.com/en-us/library/dd135715.aspx

GOTCHA #5

You may find yourself in following scenario: you have a container that stores a number of blobs. This container's contents need to be periodically updated. When updating, you want to delete previous contents of the container. If you believe in writing least amount of code, you would probably delete the container, re-create it, and upload new blobs like this:

blobContainer.Delete();
if (blobContainer.CreateIfNotExist())
{
    blobContainer.SetPermissions(new BlobContainerPermissions { PublicAccess = BlobContainerPublicAccessType.Container });
}
// start uploading new blobs

this is not going to work, and you will get a StorageClientException with the message "container does not exist" when you try to upload a blob. If you stick a breakpoint at
     blobContainer.SetPermissions(new BlobContainerPermissions { PublicAccess = BlobContainerPublicAccessType.Container });
you will find this breakpoint is not hit. Thus, it seems blobContainer.CreateIfNotExist() thinks that the container already exists even though we have deleted it in the very previous line. So what's the catch? The issue is documented here: https://social.msdn.microsoft.com/Forums/en-US/windowsazuredata/thread/f9ceaea3-be5b-40e0-a23d-bacea451d53d. Calling blobContainer.Delete(); just marks and queues up the container for deletion. When it returns, it is not guaranteed that the container has been deleted. To get around this issue, instead of calling blobContainer.Delete(), use following code:

public void EmptyContainer(string containerName)
{
   var container = client.GetContainerReference(containerName);
   if (ContainerExists(container)) 
   {
      foreach (var item in container.ListBlobs())
      {
         CloudBlob blob = new CloudBlob(item.Uri.AbsoluteUri);
         blob.Delete();
      }
   }
}

private static bool ContainerExists(CloudBlobContainer container)
{
     bool exist = true;
     try
     {
             container.FetchAttributes();
     }
     catch (StorageClientException e)
     {
            if (e.ErrorCode != StorageErrorCode.ResourceNotFound)
            {
                throw;
            }
            exist = false;
     }
     return exist;
}

Some more notes: while experimenting with high-throughput applications (applications that are uploading blobs at a high rate), I have found that the CreateIfNotExist() method is notoriously slow. How slow? Of the order of minutes. The ContainerExists method above is not faster either. It can take minutes for the FetchAttributes() call to return. Also read [this](https://social.msdn.microsoft.com/Forums/en/windowsazuredata/thread/8480223a-8cc7-4054-919c-a32ff02d5143) post that highlights concurrency issues with CreateIfNotExist(). Finally, if the container exists CreateIfNotExist() will cause a 409 in fiddler which appears highlighted in red and can lead you to think there is a bug in your code. 

Tips:

• You don't need to add reference to Microsoft.WindowsAzure.ServiceRuntime.dll. The only reference I needed to add was to Microsoft.WindowsAzure.StorageClient.dll
• If you do have a reference to Microsoft.WindowsAzure.ServiceRuntime.dll, RoleEnvironment.IsAvailable() tells whether you are running in an Azure environment or not. 

So we see its not that simple to write our first Hello World Azure app.

Q. What is Dispose, and when is it needed?
A. Dispose is C#'s answer to deterministic resource deallocation. If your class owns unmanaged resources: 1. you must implement Dispose, 2. add a finalizer to the class 3. ensure the finalizer calls Dispose. If your class only owns managed resources, implementing Dispose is optional. If you don't implement it, you would be relying on the garbage collector to do the cleanup (indeterministic resource deallocation). If your class adds any event handlers, you should implement Dispose and unhook those event handlers in it, otherwise the handlers will keep instances of the class alive, and prevent garbage collection.

Q. How to implement Dispose?
A: Case1: Your class does not own any unmanaged resources. In this case apply the basic pattern:

class MyDisposableClass : IDisposable
{
    #region IDisposable Members

    public void Dispose()
    {
        Dispose(true);  // true to indicate that managed resources should be disposed
        GC.SuppressFinalize(this);  // already disposed off the resources, so there is no need to run finalizer
    }

    #endregion

    protected virtual void Dispose(bool disposing)
    {
        if (disposing)
        {
            // dispose managed resources
        }
        // no unmanaged resources to dispose
    }
}

Notes:
1. It would be much better to rename the disposing parameter as diposeManagedResources
2. It may seem that use of disposing parameter is unnecessary, since we know beforehand that this class has only managed resources to dispose. But think about what happens when a class inherits from this class.

Case2: Your class owns unmanaged resources. In this case apply the full pattern:

class foo : IDisposable
{
    #region IDisposable Members

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    #endregion

    protected virtual void Dispose(bool disposeManagedResources)
    {
        if (disposeManagedResources)
        {
            // dispose managed resources
        }
        // dispose unmanaged resources
    }

    ~foo()
    {
        Dispose(false); // never touch managed resources on finalizer thread
    }
}

If your class inherits from a class that implements IDisposable properly, all you need to do is override the Dispose(bool) method and ensure that
1. it calls the method on the base class (not necessary as per guidelines but I don't see any reason why this shouldn't be part of the guideline)
2. it disposes off any additional resources consumed by your class
Further, if your class owns unmanaged resources, but base class doesn't, then you would need to add a finalizer on your class.
If base class owns unmanaged resources, it should have a finalizer on it, and your class should NOT add a finalizer.

Random Notes:
1. The finalizer is run unpredictably by the Garbage collector (this is what we mean by indeterministic resource deallocation) on arbitrary thread
2. The finalizer implicitly calls the base class finalizer. The above destructor method really translates to following:

protected override void Finalize()
    {
        try
        {
            Dispose(false);
        }
        finally
        {
            base.Finalize();
        }
    }

3. If your class inherits from a class that has a finalizer on it, DO NOT write a finalizer on your class.
4. The invocation of finalizer is not under your control. The finalizer is called by the Garbage Collector.
5. It is your responsibility to have the finalizer call Dispose. The Garbage Collector does NOT call Dispose automatically.

Further Reading (I have chosen 4 references from the many out there):
- https://www.codeproject.com/KB/dotnet/idisposable.aspx
- https://msdn.microsoft.com/en-us/library/66x5fx1b(VS.80).aspx
- https://haacked.com/archive/2005/11/18/ACloserLookAtDisposePattern.aspx
- https://msdn.microsoft.com/en-us/library/0s71x931(VS.71).aspx

Test it out like this

    class Foo
    {
        public Foo(bool throwException)
        {
            if (throwException)
            {
                throw new InvalidOperationException();
            }
        }

        ~Foo() { Console.WriteLine("destructor called"); }

        public void Test() { throw new InvalidOperationException(); }
    }

class Program
    {
        static void Test1()
        {
            Console.WriteLine("running Test1");
            Foo obj;
            try
            {
                obj = new Foo(true);    // ctor will throw exception
            }
            catch
            {
            }
            GC.Collect(); // destructor will be called
        }

        static void Test2()
        {
            Console.WriteLine("running Test2");
            Foo obj = new Foo(false);    // no exception in ctor
            try
            {
                obj.Test();    // exception in method
            }
            catch { }
            GC.Collect();    // destructor will NOT be called
        }

        static void Main(string[] args)
        {
            // Test1();
            Test2();            
            Console.WriteLine("done");
            Console.ReadLine();
        }
    }

This makes sense, because if an exception occurs in the constructor, then this means the object has not been constructed.
Finally, remember that in C++, destructor is automatically called whenever an exception occurs