Managing Application Settings
Application settings enable you to store and retrieve property settings and other information for your application dynamically. They also enable you to maintain custom application and user preferences on the client computer. Often this is data (such as a connection string) that is critical to running the application and that you do not want to include directly in the application's code. You might want to store two different database connection strings and retrieve one of them at run time based on the computer's location. Or you might want to store a user's color preferences and then retrieve them the next time that the application runs.
Note that application settings are a Visual Studio feature that replaces the dynamic properties feature in earlier versions.
Each application setting must have a unique name. The name can be any combination of letters, numbers, or an underscore that does not start with a number, and it cannot contain spaces. The name can be changed through the Name property.
Application settings can be stored as any data type that is XML serializable or has a TypeConverter that implements ToString/FromString. The most common types are String, Integer, and Boolean, but you can also store values as Color, Object, or as a connection string.
Application settings also contain a value. The value is set with the Value property and must match the data type of the setting.
In addition, application settings can be bound to a property of a form or control at design time.
There are two types of application settings, based on scope:
Application-scoped settings can be used for information such as a URL for a Web service or a database connection string. These values are associated with the application. Therefore, users cannot change them at run time.
User-scoped settings can be used for information such as persisting the last position of a form or a font preference. Users can change these values at run time.
You can change the type of a setting by using the Scope property.
The project system stores application settings in two XML files: an app.config file, which is created at design time when you create the first application setting; and a user.config file, which is created at run time when the user who runs the application changes the value of any user setting. Notice that changes in user settings are not written to disk unless the application specifically calls a method to do this.
At design time, you can create application settings in two ways: by using the Settings page of the Project Designer, or by using the Properties window for a form or control, which allows you to bind a setting to a property.
When you create an application-scoped setting (for example, a database connection string, or a reference to server resources), Visual Studio saves it in app.config with the <applicationSettings> tag. (Connection strings are saved under the <connectionStrings> tag.)
When you create a user-scoped setting (for example, default font, home page, or window size), Visual Studio saves it in app.config with the <userSettings> tag.
When you store connection strings in app.config, you should take precautions to avoid revealing sensitive information, such as passwords or server paths, in the connection string.
If you take connection string information from an external source, such as a user supplying a user ID and password, you must be careful to ensure that the values that you use to construct your connection string do not contain additional connection string parameters that change the behavior of your connection.
Consider using the Protected Configuration feature to encrypt sensitive information in the configuration file. See Securing Connection Strings for more information.
Because there is no configuration file model for class libraries, application settings do not apply for Class Library projects. The exception is a Visual Studio Tools for Office DLL project, which can have a configuration file.
You can add customized settings files to your project for convenient management of groups of settings. Settings that are contained in a single file are loaded and saved as a unit. Therefore, being able to store settings in separate files for frequently-used and infrequently-used groups can save time in loading and saving settings.
For example, you can add a file such as SpecialSettings.settings to your project. While your SpecialSettings class is not exposed in the My namespace, View Code can read the custom settings file that contains Partial Class SpecialSettings.
The Settings Designer first searches for the Settings.settings file that the project system creates; this is the default file that the Project Designer displays in the Settings tab. 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.
In Visual Basic projects, you can access application settings at run time by using the My.Settings object. On the Settings page, click the View code button to view the Settings.vb file. Settings.vb defines the Settings class, which enables you to handle these events on the settings class: SettingChanging, PropertyChanged, SettingsLoaded, and SettingsSaving. Notice that the Settings class in Settings.vb is a partial class that displays only the user-owned code, not the whole generated class. For more information about accessing application settings by using the My.Settings object, see Accessing Application Settings (Visual Basic).
The values of any user-scoped settings that the user changes at run time (for example, the position of a form) are stored in a user.config file. Notice that the default values are still saved in app.config.
If you have changed any user-scoped settings during run time, for example in testing the application, and want to reset these settings to their default values, click the Synchronize button.
We strongly recommend that you use the My.Settings object and the default .settings file to access settings. This is because you can use the Settings Designer to assign properties to settings, and, additionally, user settings are automatically saved before application shutdown. However, your Visual Basic application can access settings directly. In that case you have to access the MySettings class and use a custom .settings file in the root of the project. You must also save the user settings before ending the application, as you would do for a C# application; this is described in the following section.
In languages other than Visual Basic, such as Visual C#, you must access the Settings class directly, as shown in the following Visual C# example.
You must also explicitly call the Save method of this wrapper class in order to persist the user settings. You usually do this in the Closing event handler of the main form. The following Visual C# example shows a call to the Save method.
For a specific example of how to create new application settings and bind them to properties on a form, see How to: Create Application Settings Using the Designer. For more general information about accessing application settings through the Settings class, see Application Settings Overview.