The Azure Development Fabric is quite useful as far as simulating Azure on your dev box, It is especially nice how it simulates mulitple web roles and worker roles, so you can find web farm problems and what not before deploying. But, one hassle when working in the dev fabric is that once you start debugging, it creates a package and "deploys" the files, so that you can't make any changes to the site and hit refresh. So, no changes to CSS, static html pages or .aspx pages. This is kind of a drag.

I thought the solution would be as simple as just creating a different .sln that wasn't an Azure project and then adding the .csproj file to that .sln.  But, I tried that and got the following error:

"SetConfigurationSettingPublisher needs to be called before FromConfigurationSetting can be used."

Basically, what was happening was that any code that tried to call CloudStorageAccount.FromConfigurationSetting was failing because it couldn't get to the Azure config, which is where I have stored the connection string to my blob storage.

At first, I was going to just get rid of using the CloudStorageAccount and move my config elsewhere, but I briefly searched my code and found I was using it a lot. And, if I removed it out of there, I could no longer make any changes to config after I deployed. I found a more elegant solution (tip o' the hat to Fernando Tubio and this thread in the Azure forums.)  Basically, I duplicate the settings in web.config and then call the following code in Application_Start() of global.asax.cs:

CloudStorageAccount.SetConfigurationSettingPublisher((configName, configSetter) =>
  {
    string connectionString;

    if (RoleEnvironment.IsAvailable)
    {
      connectionString = RoleEnvironment.GetConfigurationSettingValue(configName);
    }
    else
    {
      connectionString = ConfigurationManager.AppSettings[configName];
    }

    configSetter(connectionString);
  });

Works great! And makes for a much better development experience!

Oh, the one other thing I had to do was rem out the diagnostics trace listener in web.config. If I wanted to be more elegant, I could have removed this from web.config programmatically in the conditional statement above...