La piattaforma Windows Azure oltre ai servizi di storage offre la possibilità di eseguire codice e di ospitare applicazioni internet attraverso i role. Sono di due tipologie, web e worker, e nella maggior parte dei casi si poggiano a SQL Azure piuttosto che hai i servizi di storage per memorizzare informazioni, gestire code o mantenere informazioni in forma tabellare.

Di fatto i role sono macchine virtuali Windows Server 2008 dedicate esclusivamente ad ospitare il codice installato attraverso i pacchetti di deployment e teoricamente è possibile accedere al suo file system, al registro e a tutte le informazioni di sistema. Tutto questo in realtà non è possibile per le restrizioni di scrittura imposte dal sistema, anche se il ruolo è stato configurato per funzionare in Full trust, dove è consentito accedere in sola lettura alle cartelle di sistema o alla directory dell'applicazione.

Per ovviare a questo problema in Windows Azure sono disponibili i local storage, cartelle di cui si ha il pieno controllo e dove è possibile inserire tutti i file e sotto cartelle che si necessitano. Per sfruttarli occorre prima di tutto configurare nelle impostazioni del ruolo (pannello local storage), una lista di storage identificati dal nome, dallo spazio che hanno a disposizione e dal flag che indica se lo storage viene svuotato quando il ruolo viene reciclato.

In questo modo il sistema riserva uno spazio riservato su disco raggiungibile attraverso uno specifico percorso, ottenibile con il metodo statico RoleEnvironment.GetLocalResource. Effettuata questa chiamata si ottiene un oggetto LocalResource la cui proprietà RootPath restituisce l'intero percorso alla directory. Con esso è possibile combinare le classi di System.IO e in particolare File e Path per creare percorsi, scrivere file ecc, come nell'esempio seguente.

string path = RoleEnvironment.GetLocalResource("test").RootPath;
string file = Path.Combine(path, "test.txt");
File.WriteAllText(file, "Ciao!");

Il metodo è funzionante anche nell'ambiente di sviluppo e restituisce un percorso all'interno dell'appdata dell'utente o in C:\Resources\directory\xxx se avviato in the cloud. Gli storage sono, ad ogni modo, pensati per fornire velocità nella scrittura e lettura delle informazioni, ma non adatti per esporre informazioni agli utenti, ruolo più adatto, anche in termini di scalabilità, agli storage blob di Windows Azure. Non è infatti assicurato che il contenuto dello storage non venga perso, a causa di sospensioni o rimozioni dei deployment. Infine occorre prestare attenzione ai limiti dello storage locale e a quelli dell'intera macchina, variabili in base alla dimensione del ruolo. Per questo motivo si rimanda al sito ufficiale:
http://msdn.microsoft.com/en-us/library/ee814754.aspx