Windows Azure: Settings Are Settings Are Settings..? Maybe Not!

So I’m back from Oz and have been tinkering with a small worker role app that grabs my Twitter feed and aggregates how many posts my friends have been doing as a scoreboard (I’ll post that tomorrow).

One of the design decisions I’ve had to make has been where to store the configuration settings.

See, in Windows Azure, you can either:

• Store your configuration settings using the App.config file for your project, then use the standard libraries from .NET to read those, or
• Use the ConfigurationSettings element within your Service Configuration and Service Definition files, and use the RoleManager.GetConfigurationSetting() method to read the setting

What’s the diff?

Well, when you store your settings in your Service Configuration and Definition files, you are able to change those settings without having to redeploy your application. If you use the App.config file, any change you make won’t be picked up until you redeploy your app.

Allow me to demonstrate.

So, first you need to define your setting in your ServiceDefinition file:

And add the ConfigurationSetting section into it:

 <?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="SettingsExample" 
                   xmlns="https://schemas.microsoft.com/_
                   ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="WebRole">
    <InputEndpoints>
      <!-- Must use port 80 for http and port 443 
      for https when running in the cloud -->
      <InputEndpoint name="HttpIn" protocol="http" port="80" />
    </InputEndpoints>
    <ConfigurationSettings>
      <Setting name="DefaultWelcome"/>
    </ConfigurationSettings>
  </WebRole>
</ServiceDefinition>

Next, define some values in the ServiceConfiguration file:

And set the values:

 <?xml version="1.0"?>
<ServiceConfiguration serviceName="SettingsExample" 
                      xmlns="https://schemas.microsoft.com/_
                      ServiceHosting/2008/10/ServiceConfiguration">
  <Role name="WebRole">
    <Instances count="1"/>
    <ConfigurationSettings>
      <Setting name="DefaultWelcome" value="Manishkta"/>
    </ConfigurationSettings>
  </Role>
</ServiceConfiguration>

Next, you need to access your setting in your app, so you use the RoleManager.GetConfigurationSetting() to read it, like so:

 using Microsoft.ServiceHosting.ServiceRuntime;

namespace SettingsExample_WebRole
{
    public partial class _Default : System.Web.UI.Page
    {
        protected void Button1_Click(object sender, EventArgs e)
        {
            lblGreeting.Text = 
            RoleManager.GetConfigurationSetting("DefaultWelcome") + 
            " " + txtName.Text;
        }
    }
}

Then deploy your app:

Now, when I run my app, it pulls the setting from my Windows Azure app deployment:

Next, let’s go change the setting live without messing with our deployment, to start, click the configure button:

Then change and save the setting:

Windows Azure will reconfig your app:

And it will now use the new setting:

This saves you from having to completely package up and redeploy your app every time you want to change a setting (due to changes in business rules or between production and staging environments for example).

Also, if you want to know how to paste code into your posts, check out this Live Writer Add-in! It rocks!

Chau :)

Technorati Tags: Windows Azure,Settings

Comments

• Anonymous
  March 05, 2009
  So why exactly is this? Does the service definition configuration items get reloaded into a cache when its reconfiguring ("package is updating") and the call to GetConfigurationSetting() just hits the cache, OR does it actually hit the service definition file on every request to GetConfigurationSetting() ? The answer is important because it affects performance. If I move more settings into the service definition, and my app has constant dependency on these settings, then will it suffer perf? Something else to consider is the way we code using settings. For example, its not uncommon for singleton to get created utilising a setting. If the singleton is long lived, then you can change the settings in the service def until you are blue in the face, it won't make a difference to the app. I guess its just something else you have to think about when writing your apps for Azure.

• Anonymous
  March 06, 2009
  Thank you for submitting this cool story - Trackback from DotNetShoutout