7

I connect to a blob store programatically:

string connectionString = CloudConfigurationManager.GetSetting("StorageConnectionString");
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(connectionString);
CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();
...

My App.Config settings are:

<configuration>
  <appSettings>
    <add key="StorageConnectionString"
         value="DefaultEndpointsProtocol=http;AccountName=ACNAME;AccountKey=MYKEY==" />
  </appSettings>
...

The connection works. However I see the message "Getting "StorageConnectionString" from ServiceRuntime: FAIL" on my local unit tests:

enter image description here

What is the reason for this message and how I can fix it?

Miroslav Popov
  • 3,294
  • 4
  • 32
  • 55

3 Answers3

10

I had the same problem with Azure Table Storage, but everything works.

Add to your web.config :

<connectionStrings>
    <add name="ConnectionTableAzure" connectionString="DefaultEndpointsProtocol=https;AccountName=[ACCOUNTNAMEHERE];AccountKey=[ACCOUNTKEYHERE];TableEndpoint=[ENDPOINTHERE]"/>
</connectionStrings>

Replace :

storageAccount = CloudStorageAccount.Parse(CloudConfigurationManager.GetSetting("ConnectionTableAzure"));

By this :

storageAccount = CloudStorageAccount.Parse(ConfigurationManager.ConnectionStrings["ConnectionTableAzure"].ConnectionString);
rrrr-o
  • 2,447
  • 2
  • 24
  • 52
SoEz
  • 116
  • 1
  • 4
2

The previous solutions works, but I would like to expand more on it.

It replaces values even if the code runs in production, however sometimes you really want to let Azure handle the configuration, while keeping control of your output window while debugging.

I created the following class to help with that.

public static class CloudConfigurationManagerExt
{
    public static string GetSetting(string configurationValue)
    {
#if DEBUG
        return System.Configuration.ConfigurationManager.AppSettings[configurationValue];
#else
        return Microsoft.Azure.CloudConfigurationManager.GetSetting(configurationValue);
#endif
    }
}

then I changed all the calls to CouldConfigurationManager.GetSetting to mine.

From

string connStr = CloudConfigurationManager.GetSetting("Microsoft.AzureBlobStorage.ConnectionString");

To

string connStr = CloudConfigurationManagerExt.GetSetting("Microsoft.AzureBlobStorage.ConnectionString");

and added the setting in the appSetting part of the web.config, or app.config as needed.

web.config

<add key="Microsoft.AzureBlobStorage.ConnectionString" value="YourValueHere" />

As you can see. If you are running in debug mode, it gets the value from the appsetting, else follows the regular path for CloudConfigurationManager.GetSetting

0

The CloudConfigurationManager.GetSetting function is overloaded and by default, it will write its results to the Trace log.

The following overload will prevent those messages:

var connStr = CloudConfigurationManager.GetSetting("StorageConnectionString", false);

Assuming the value is located in appSettings, another option is to directly access it via the regular ConfigurationManager.

var connStr = System.Configuration.ConfigurationManager.AppSettings["StorageConnectionString"];

Sidenote: You might want to consider creating an IConfigFileProvider with a default implementation that accesses the .config file values by key name. Then you can create a secondary implementation to use in your unit tests (or elsewhere) that uses a dictionary to house the values. Depending on what you're doing, you might use one or the other.

In the IConfigFileProvider, you would define functions that automatically return the settings by name, using a default value, type converted (to int, for example), or throw exceptions if the value wasn't found.

I use this approach and it works really well. It allows you to test different config value settings without using a completely different project to do it, while at the same time not forcing you to make changes to your class libraries that might already depend on the config files. So long as you're always retrieving .config settings from an IConfigFileProvider, you're fine.

Mike Taber
  • 833
  • 6
  • 21