One reason is user isolation, or the lack thereof. The information in App.Config is common to all users of the system. This defeats an important purpose of saving user settings, which is to allow each user to save his own settings separately from all other users.

Another reason is permissions. In a proper installation, App.Config is placed in the application folder under Program Files. If the system security is set up properly, normal users do not have write permission for this folder; only administrators do.

So, where do you keep user settings? Rumor has it that the next release of .Net will include support for user settings. Until then, you have to roll your own. Fortunately it is not difficult.

User Settings

Creating an object to hold user settings is a trivial matter. Just define properties or public variables to hold all the information that is needed. The difficulties arise when you consider that you have to (1) Save the information to disk, and (2) Save it in a manner that is specific for each user. Let's look at these in turn.

For saving the user settings to disk, we use serialization, a fancy term for converting an object into a series of bytes that can be sent over a network or saved to disk. This data can then be deserialized, giving you an exact copy of the original object. The plan, then, is to:

1. Create an object that contains the user settings data.
2. When the program quits, serialize it to disk.
3. When the program starts, deserialize the disk data to retrieve the object and the user settings it contains. Of course, the first time the program runs, there will be no serialized data so the program will use default settings.

When you create a class that will be serialized, you must mark it with the <Serializable()> attribute. Here is a simple UserSettings class that stores the position and size of the program window:

<Serializable()> Public Class UserSettings
  Public WindowTop As Integer
  Public WindowLeft As Integer
  Public WindowWidth As Integer
  Public WindowHeight As Integer
End Class

Your program will create an instance of this class and store the required data in it. Then, when the program is closing, the object must be serialized as shown here. You might put this code in the form's Closing event procedure, although that is not the only option. Assume that us is the reference to the object and the variable filename contains the target file name:

Dim fs As New FileStream(filename, FileMode.Create)
Dim f As New BinaryFormatter
f.Serialize(fs, us)
fs.Close()

Your program does, of course, need the following Imports to work:

Imports System.IO
Imports System.Runtime.Serialization.Formatters.Binary
Imports System.Runtime.Serialization

And In The Other Direction...

Serializing an object to disk is quite simple. Deserializing it is equally simple.

You need to make sure that the file exists. If it does not, which is the case the first time the program is run (and also if the file is deleted for whatever reason), the program skips the deserialization and uses default values for whatever settings would have been in the file. These steps are typically done in the form's Load event procedure, as shown here.

' The variable us has been declared elsewhere.
us = New UserSettings 
If File.Exists(filename) Then
  Dim fs As Stream = File.OpenRead(filename)
  Dim ds As New BinaryFormatter
  us = CType(ds.Deserialize(fs), UserSettings)
  fs.Close()
Else
  ' Use default settings.
End If

After this code executes, the object us contains the same data that it did when the program last terminated.

Now let's look at the second problem: how to serialize the data to a file that is unique and associated with a specific user? The main element of this is selecting a folder that "belongs" to the specific user. There are two choices that I am aware of. The first is the Application.UserAppDataPath property which returns a path as follows:

C:\Documents and Settings\userid\Application Data\company\product\version

This is typical, although the drive letter and first level folder may vary on some systems. In this path, userid is the ID of the current user, and company\product\version are information associated with the application's assembly. This location would be ideal for storage of user settings except for one thing: if the application is updated to a new version, the stored user information will be lost. The other option is to use System.Environment.GetFolderPath, which returns a path like this:

C:\Documents and Settings\userid\Application Data

This location is safe against version changes, but is common to multiple applications, so there is the theoretical possibility that another application could overwrite your user data file. However, by assigning a file name that is related to the application name, you should be safe against this possibility.

Saving user settings can be an important part of creating a user-friendly application. Saving them the right way is part of good programming practice. Once you know the factors that are involved it is really rather easy.