Geeks With Blogs
Doug.Instance Improving the world one post at a time

First off, please see my internet PSA at the bottom of this post on the difference between “yea”, “yeah”, and “yay”.  Now that that is out of the way, I want to talk about settings.  Almost every settings example provided by Microsoft will look something like this which happens to be from the Azure queue documentation:

<configuration>
    <appSettings>
        <add key="StorageConnectionString" value="DefaultEndpointsProtocol=https;AccountName=account-name;AccountKey=account-key" />
    </appSettings>
</configuration>

 

I have seen this type of thing so many times that it caused me to question my own sanity.  Maybe there is a good reason for this.  I have a theory – it is easier to have a completely working demo when all of the configuration can be performed in your config file and code.  Using strongly-typed settings has multiple advantages but it takes a little more instruction to implement so include that little bit of how-to in every demo is unnecessary.  I have no idea why Microsoft uses appSettings for other common code, but let’s just say I hope one day this type of thing disappears:

<appSettings>
  <add key="webpages:Version" value="3.0.0.0" />
  <add key="webpages:Enabled" value="false" />
  <add key="ClientValidationEnabled" value="false" />
  <add key="UnobtrusiveJavaScriptEnabled" value="false" />
</appSettings>

Why Not appSettings?

The biggest difference between appSettings and applicationSettings is that applicationSettings are “strongly-typed”.  The best way to illustrate this is by showing how “appSettings” are NOT strongly typed.  As you see in the example above, appSettings can be added with an “add” XML element with two attributes: “key” and “value”.  Both “key” and “value” are treated as strings.  Therefore the setting above can be retrieved with the following code:

CloudConfigurationManager.GetSetting("StorageConnectionString")

 

This code passes the key in as a string and returns the value as a string (“DefaultEndpointsProtocol=https;AccountName=account-name;AccountKey=account-key”).  While that is OK if you are dealing with strings, it introduces some challenges if your code gets complex or if you use open source projects or other third-party code.  The problem arises because every value of “key” in appSettings must be unique.  That means you have to plan ahead and make sure your keys are unique and hope the third-party code you use does the same.

Why applicationSettings?

Now let’s add the same key using applicationSettings.  The first thing you will need to do is add a settings file to your project.  You MUST add this settings file to the project that will read the settings.  In the example below, I am adding this setting to an Azure WorkerRole project called “MyWorkerRole”, but this could be any project (web application, class library, etc.).  First access the project properties by either right-clicking on the project and select “Properties” or double-clicking “Properties” in inside the project in Solution Explorer.  Then select the Settings tab and click the link to add a settings file shown below.

image

Then add the setting.  Note that the default scope is “User”.  For client applications, this allows you to have settings that can be configured for each individual user.  For web applications and other server-side uses, you will need to change the scope to “Application”.  Note that the default variable type is “string” but you can select from common .Net types and also types defined in code.  Set the “Name” value to the desired name and enter the value in the “Value” property.

image

Now to retrieve this setting, we can just use the following property automatically added to a default instance of your strongly-typed settings:

    Properties.Settings.Default.StorageConnectionString

One of the benefits of this syntax is that the settings are compiled into your project.  This means you get intellisense on the settings properties (i.e. “StorageConnectionString”) so you don’t have to rely on string constants (AKA “magic strings”) to retrieve your settings.  Also, the values are strongly-typed.  If you select “bool” or “int” as the Type in your settings file, that property will evaluate as that type in your code.  No parsing or type conversion required!

One Last Thing!

Since we are using strongly-typed settings that must be stored in the project where the settings are created, the most common mistake you will make is forgetting to put the settings in the project where they are used.  Luckily this is easy since Visual Studio puts the settings in the app.config (or web.config) of the project where you created them.  Simply copy and paste the values into the config file of your main project (i.e. web.config in your web application).  Below is a sample config file.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
            <section name="MyWorkerRole.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
        </sectionGroup>
    </configSections>
    <applicationSettings>
        <MyWorkerRole.Properties.Settings>
            <setting name="StorageConnectionString" serializeAs="String">
                <value>DefaultEndpointsProtocol=https;AccountName=account-name;AccountKey=account-key</value>
            </setting>
        </MyWorkerRole.Properties.Settings>
    </applicationSettings>
</configuration>

In the “configSections” element, we define applicationSettings section and the specific settings section “MyWorkerRole.Properties.Settings”.  Note that this section name uses the namespace of the project so as long as your namespace is unique, your settings will be unique.  The best practice is to start your namespace with your company name or other unique identifier so a better namespace (and therefore project name) would be something like “MyCompany.MyProject.WorkerRole”.  Note that inside the “applicationSettings” section, there is a strongly-typed section with the same name as the sectionGroup defined above (“MyWorkerRole.Properties.Settings”).  This is where you can change your values.  You can also use standard xdt transformations to replace values based on build configurations.  For example, this is how you could do this in something like web.Release.config:

<applicationSettings>
    <MyWorkerRole.Properties.Settings>
        <setting name="StorageConnectionString" serializeAs="String" xdt:Locator="Match(name)">
            <value xdt:Transform="Replace">New value goes here</value>
        </setting>
    </MyWorkerRole.Properties.Settings>
</applicationSettings>

There is a potential benefit of appSettings in that various web-based GUIs allow you to modify values in appSettings. Since strongly-typed applicationSettings sections are dependent on the code, you usually have to modify the text or use this xdt transformation during publication to make changes on your server.

Internet Public Service Announcement

If you want to affirm something, then “yea” is probably your word.  This is pronounced “yay” and means “yes I approve” as in voting “yea” or “nay”.  Most likely, when you say “yay” you really mean “yea”.  If you say “yeah”, that is slang for “yes” and pronounced with a short “a” as in “as”.  If you use “yeah”, it probably isn’t inappropriate but it probably isn’t what you mean to say.  If you want to exclaim excitement, then you probably want to use “yay”.  Honestly I wasn’t sure that was a “real word” until I did some research.  Basically it is the exclamatory version of “yea”.  So much like all blimps are dirigibles but not all dirigibles are blimps, “yay” always means “yea” but “yea” does not always mean “yay”.  “Yeah” means “yes” and “yea” means “yes” but not always in the same way.  “Yeah” can mean “yay” but is never pronounced “yay”.

Posted on Monday, November 10, 2014 6:31 PM | Back to top


Comments on this post: Boo appSettings! Yay applicationSettings!

# re: Boo appSettings! Yay applicationSettings!
Requesting Gravatar...
Hello Doug, nice article! The transform of application settings is very useful. I use it in collaboration with the ConfigurationTransform tool, made by Golan Avraham (can be found in the visual studio marketplace), so that we can also apply it to App.config in non-web projects. Initialy I thought (perhaps read it somewhere) that these transforms where only applicable to certain parts of the config file. like connectionstring and appSettings, but not applicationSettings. It turns out (thanks to your article) that also applicationSettings can be transformed.

regards, Vincent
Left by Vincent on Oct 05, 2017 3:22 AM

Your comment:
 (will show your gravatar)


Copyright © Doug Lampe | Powered by: GeeksWithBlogs.net