Saving Settings in .NET 2.0 Apps, Part 2

With .NET 2.0, Microsoft decided to completely overhaul how application settings are stored by providing a new namespace (System.Configuration). The resulting new technology fully implements solutions for each of the specific issues we briefly looked at last time and we’ll take a closer look at what it is and how to use it in the issue.

The key class within the System.Configuration namespace that we’ll need for application settings is called ApplicationSettingsBase. This class is the base class of any object that you wish to serialize to a settings file. Unlike in .NET 1.1, the ApplicationSettingsBase class requires that developers treat their settings as members of an object that is serialized not a bunch of name/value pairs that are simply read from a file. Typically, each setting is exposed from a derived class as a property with a setter/getter allowing full access to the value while hiding how it is retrieved or stored in the settings file.

Let’s first take a look at how the ApplicationSettingsBase class has updated where settings are stored. As in .NET 1.1, application settings are typically accessed from the .config file associated with the application executable. However, in .NET 2.0, the format of the sections dealing with settings has dramatically changed as you can see below:

<?xml version="1.0" encoding="utf-8"
?>
<configuration>
    <configSections>
     <sectionGroup name="userSettings"
     type="System.Configuration.UserSettingsGroup, 
     System, Version=2.0.0.0,
     Culture=neutral, PublicKeyToken=b77a5c561934e089" >
         <section name="ApplicationSettings.Properties.Settings"
         type="System.Configuration.ClientSettingsSection, System, 
         Version=2.0.0.0,
         Culture=neutral, PublicKeyToken=b77a5c561934e089"
          allowExeDefinition="MachineToLocalUser"
         requirePermission="false" />
     </sectionGroup>
     <sectionGroup name="applicationSettings"
         type="System.Configuration.ApplicationSettingsGroup, 
         System, Version=2.0.0.0, Culture=neutral, 
         PublicKeyToken=b77a5c561934e089" >
         <section name="ApplicationSettings.Properties.Settings"
         type="System.Configuration.ClientSettingsSection, 
         System, Version=2.0.0.0,
         Culture=neutral, PublicKeyToken=b77a5c561934e089" 
         requirePermission="false"
         />
     </sectionGroup>
    </configSections>
    <userSettings>
     <ApplicationSettings.Properties.Settings>
         <setting name="LastPath"
         serializeAs="String">
         <value>C:\Program Files\MyCo\MyApp</value>
         </setting>
     </ApplicationSettings.Properties.Settings>
    </userSettings>
    <applicationSettings>
     <ApplicationSettings.Properties.Settings>
         <setting name="RegPath"
         serializeAs="String">
         <value>Software\MyCo\MyApp\RegPath</value>
         </setting>
     </ApplicationSettings.Properties.Settings>
    </applicationSettings>
</configuration>

At first glance, the format of the XML in this file can be a bit overwhelming. Instead of a single appSettings section with the configuration section, there is now a configSections section which lists the set of sections contained in the file and their attributes followed by the specific sections themselves with their settings. You may have noticed that the name of a settings section such as ApplicationSettings.Properties.Settings is used in the sectionGroup section as the section name. This name acts as a key into the file so that the specific settings for that item can be located.

The settings for an individual section appear as serialized values on the class that wraps the settings themselves. Notice that unlike .NET 1.1, this new layout separates application-level and user-level settings into distinct groups. This is particularly important for those settings which are user-specific and where multiple users may run the same application on a given computer. However, it’s not necessary to actual hand-edit this file as it was in the .NET 1.1 version of the .config. Instead, VS.NET 2005 allows for editing these values within the environment as properties of the project:

Each setting can be specified with a data type, a scope and a default value. The data type provides for many common .NET types and base types such as System.Boolean, System.Integer, etc. Each of these types must be serializable in order to be used as a setting type. The scope provides for either a user-level or application-level value which is tied to the type of the setting; a System.Boolean type restricts the possible values to either True or False as you would expect.

To utilize these settings once created, you only have to access the static Settings object within the Settings class that is part of the ApplicationSettings.Properties namespace as follows (in C#):

 string mySetting = Properties.Settings.Default.RegPath;
 

The settings specified in the Project Settings window are essentially serialized properties of a Settings class instance created for you by VS.NET and .NET 2.0. The name of each setting becomes the name of the property accessor within the class. This makes it amazingly simple to find and use available settings with Intellisense since each setting will appear in the list of choices:

Even better, since the settings are accessed within code by name any changes to the setting names in the Project Properties window will cause compilation errors later if they are not modified. No more latent bugs in the source code because someone forgot to modify the code to account for the new name.