Easily Save and Retrieve Application and User Settings in VB.NET or C# Apps

We used to save our application or user settings in an INI file (dark ages) or more recently in XML files using our own code or classes borrowed from other developers. But applications built with the .NET framework using Visual Studio can take advantage of built-in tools to simplify or speed up access and saving of runtime values. Once common example is saving database connection string information in a configuration file so that it may be changed without need to recompile the application.

Here are some simple examples in VB.NET. C# code uses a slightly different syntax the concepts are similar. The following examples are using Visual Studio 2008 and VB.NET.

The Basics

Each value you want to use in your application is defined as simple name=value pairs and saved in special XML files. You also define a data type such as string, integer, date, even special types such as connection string. You also choose  the scope of the value. Only two possible scopes are available:

• Application – is read-only at runtime; you can edit a value and have the app use without recompiling.
• User – is read / write at runtime; values are saved at the Windows user account level and good for user prefs.

If you need the application so save the value at runtime such as a user preference, then choose User as your scope, otherwise you would choose Application as the scope.

Define Your Values in Visual Studio

Go to your project properties, then click the settings tab on the left. There you can define one or more values to be used by your application. For each value you will choose the data type, scope and a default value. These values will be saved in a file named app.config in your project folder and in a file named {yourappname.exe}.config in output folders after builds such as \bin\Debug\ if building in debug mode.

In you VB.NET code, you can access values defined above using syntax like this.

TextBox1_Subject.Text = My.Settings.Subject
TextBox_FromAddress.Text = My.Settings.FromAddress
TextBox_FromName.Text = My.Settings.FromName

If the value is defined with a scope of User, then you can save the value back to an XML file for later retrieval. Below, the code checks for a value in a textbox an then assigns the value to the Settings object which will be later saved.

If TextBox1_Subject.Text.Trim.Length > 0 Then
    My.Settings.Subject = TextBox1_Subject.Text.Trim
End If

Note that the values in the Settings object are not actually saved until…

• You issue a My.Settings.Save() method call.. or…
• You set a project level attribute to save the value when application exits (either in VS or programmatically).

The project level attribute mentioned above is typically already set in a new project. In VS 2008, go back to your project properties and click the tab labled Application. There you will see the checkbox that controls this setting (see image). When this value is checked, any User scoped values you have set back to the Settings object will be automatically saved. You might think these value are saved back to the app.config file or the {yourappname.exe}.config files mentioned previously but unfortunately no as that would be too easy. Because they are scoped as User, the values are stored in a new XML file created below the C:\Users\{username}\AppData\ folder and named user.config. For example, my file was created at the following location: C:\Users\don\AppData\Local\Microsoft\EmailSenderNet.vshost.exe_Url_layp1zjs3efmh3nnxgs3wj0if0kd3vz0\1.0.0.0\user.config.  If different users login and use your application, each user can maintain their own separate and unique values making them perfect for user specific preferences.

Another example of the path is this…

C:\Documents and Settings\[username]\Local Settings\Application Data\[AssemblyCompanyName]\[NameOfProject].[SomeLongUniqueString]\[AssemblyVersion]\user.config.

Note that the Assembly Version is the last folder in the path. This means that when you change the assembly version of your application, your User scoped values will be saved in a completely new user.config file. This is actually clever and ensures that each version of your application does not clash or overwrite values from a previous version.

So what happens to the values in the previous app.config and {yourappname.exe}.config files in the output folders? They are really just default values that your application can access at runtime if needed. The app.config is used directly by VS 2008 and updated when you edit the values in the VS project properties settings pane. The {yourappname.exe}.config files in the output folders are copies that can be distributed with your EXE in the same folder.

But remember that when you deploy the EXE, the only values that your application will read from the {yourappname.exe}.config file are Application scoped values. Any User scoped values will be read from the user.config mentioned above.

Synchronize Often

If you been able get this far without falling asleep, you have probably pondered the concept that with so many files holding the same data that things could get out of sync. Or perhaps you are one of the many developers who gave up on using the app.config file because it never seemed to work or would pull up the incorrect values when accessing them in code. Well the reason is because they do get out of sync. And to remedy that problem, Microsoft provided a Synchronize button in the Visual Studio Settings pane as well as programmatic controls. This button will sync the config files and delete and create new user.config files if you have any User scoped values.

The tip here is use the Synchronize button anytime you change the values in the Visual Studio Settings pane.

Summary

While far from perfect and a bit overly complicated, Visual Studio and the .NET framework offer an a quick and easy option for storing and accessing data for your application. They offer tremendous power and flexibility. For example, you can add customized settings files to your project for management of settings in different groups. This allows you to save settings for a group or subset of values in separate files which can save saving and loading time.

For example you can add a special MySettings.settings file to your project. The Settings Designer first searches for the Settings.settings file (default file) that the project system creates Settings.settings is located in the My Project folder for Visual Basic projects and in the Properties folder for Visual C# projects. The Project Designer then searches for other settings files in the project’s root folder. Therefore, you should put your custom settings file there. If you add a .settings file elsewhere in your project, the Project Designer will not be able to locate it.

Well I hope this helps. If you don’t already have a custom class for managing application values or if you just need something fast and easy for a simple utility app, then give the built-in options a try. If you can take the time to read and understand the basics, you will be glad you did.