Todos sabemos que en Windows Azure existe una simulador de cómputo y otro del storage. Y que el simulador de storage usa tecnología SQL Server (puede estar en uno full, en una versión Express o hasta en LocalDB!

Sabemos que si creamos un Cloud Service convencional, éste se autoconfigura para usar el Storage Emulator y luego uno cambia la conexión con datos de una cadena real.

Pero si estamos hacienda una solución Azure bien personalizada (por ejemplo una app de consola que se conecta a Azure), entonces cómo hacemos para configurar este DevelopmentStorage manualmente?

Primero un dato curioso y bien interesante:

La Developer Storage Account tiene un nombre y un PAK (Primary Acces Key) bien definidos! Y son los mismos en cualquier lado que se use… por eso es obvio que no debemos usarla para producción. Pues bien, esos datos son:

Account name: devstoreaccount1
Account key: Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==

Entonces ya tendríamos mucha de la información para armar la cadena de conexión manualmente… sin embargo, una conexión al storage de Azure es de la forma:

"DefaultEndpointsProtocol={0};AccountName={1};AccountKey={2}"

Así que nos faltaría indicar el DefaultEndpointsProtocol (en general es http o https); pero el Development Storage no soporta HTTP, así que no podríamos poner nada… la solución que nos da el SDK es que sencillamente como cadena de conexión escribamos: UseDevelopmentStorage=true así, sin clave, tal como aparece… de esta manera, nuestro proyecto siempre la tomará como la cuenta de acceso al Development Storage.

 

Cuando ya necesitemos probar contra el storage real en Azure, ahí sí que tendremos un nombre y una PAK. Además decidiremos si enviamos por http o https. Y en ese caso, solo será necesario reemplazar los placeholders en la sentencia que describí. Al final en C# podríamos escribir:

if (!CloudStorageAccount.TryParse(strConnection, out _storageAccount))

Entonces si strConnection viene con el formato adecuado, el TryParse funciona y la cuenta de almacenamiento ya queda instanciada en _storageAccount, desde donde se podrán crear los clients de blobs, colas y tablas, independientemente si hemos pasado la cadena de DevelopmentStorage o la de un Storage en Azure.

Para finalizar, si no requerimos comportamiento dinámico y sabemos que solo usaremos por ahora la cuenta del DevelopmentStorage podemos sencíllamente escribir:

var account = CloudStorageAccount.DevelopmentStorageAccount;