The Application Settings subsystem allows you to create strongly-typed settings, on a per-user or per-application basis. Just right-click the project, choose Properties, and click on the Settings tab.
From Application Settings Overview:
Application settings addresses both
needs by providing an easy way to
store both application-scoped and
user-scoped settings on the client
computer. Using Visual Studio or a
code editor, you define a setting for
a given property by specifying its
name, data type, and scope
(application or user). You can even
place related settings into named
groups for easier use and readability.
Once defined, these settings are
persisted and read back into memory
automatically at run time. A pluggable
architecture enables the persistence
mechanism to be changed, but by
default, the local file system is
used.
Application settings works by
persisting data as XML to different
configuration (.config) files,
corresponding to whether the setting
is application-scoped or user-scoped.
In most cases, the application-scoped
settings are read-only; because they
are program information, you will
typically not need to overwrite them.
By contrast, user-scoped settings can
be read and written safely at run
time, even if your application runs
under partial trust. For more
information about partial trust, see
Security in Windows Forms Overview.
When you add a setting, Visual Studio creates a strongly-typed property in the settings class. It also creates an entry in the application config file. For an Application setting, this is the actual value of the setting. You could change it at installation time, if you like. For a User setting, this is the default value of the setting. The user can change the value at runtime. You can then call the Save method to save the changed value. The current value of User settings is stored in a user.config file stored in the correct per-user folder, based on whether the user is roaming, local, etc.
It's really very nice when used with Windows Forms, since various properties of forms and controls can be bound to application settings at design time. This means that when the application starts, these properties will take their initial values from the settings. If the values change at runtime, the settings will change. You can then save the changed settings before the application exits. They will then automatically be used when the application starts again. This takes very little code.
Even though these were created for Windows Forms in .NET 2.0, I've used them with other project types, especially unit test projects. Of course, in that situation, you have no per-user settings.