Your Windows Forms applications will often require data that is critical to running the application, but which you do not want to include directly in the application's code. If your application uses a Web Service or a database server, you may want to store this information in a separate file, so that you can change it in the future without re-compiling. Similarly, your applications may require storing data that is specific to the current user. Most applications, for example, have user preferences that customize the application's appearance and behavior.

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.

Settings are stored as XML fragments in configuration files. Application-scoped settings are represented by the <application.Settings> element, and generally are placed in app.exe.config, where app is the name of your main executable file. User-scoped settings are represented by the <userSettings> element and are placed in user.config, where user is the user name of the person currently running the application. You must deploy the app.exe.config file with your application; the settings architecture will create the user.config files on demand the first time the application saves settings for that user. You can also define a <userSettings> block within app.exe.config to provide default values for user-scoped settings.

Custom controls can also save their own settings by implementing the IPersistComponentSettings interface, which exposes the SaveSettings method. The Windows Forms ToolStrip control implements this interface to save the position of toolbars and toolbar items between application sessions. For more information about custom controls and application settings, see Application Settings for Custom Controls.

You cannot use application settings in an unmanaged application that hosts the .NET Framework. Settings will not work in such environments as Visual Studio add-ins, C++ for Microsoft Office, control hosting in Internet Explorer, or Microsoft Outlook add-ins and projects.

You currently cannot bind to some properties in Windows Forms. The most notable example is the ClientSize property, as binding to this property would cause unpredictable behavior at run time. You can usually work around these issues by saving and loading these settings programmatically.

Application settings has no built-in facility for encrypting information automatically. You should never store security-related information, such as database passwords, in clear text. If you want to store such sensitive information, you as the application developer are responsible for making sure it is secure. If you want to store connection strings, we recommend that you use Windows Integrated Security and not resort to hard-coding passwords into the URL. For more information, see Code Access Security and ADO.NET.

If you use Visual Studio, you can define settings within the Windows Forms Designer using the (ApplicationSettings) property in the Properties window. When you define settings this way, Visual Studio automatically creates a custom managed wrapper class which associates each setting with a class property. Visual Studio also takes care of binding the setting to a property on a form or control so that the control's settings are restored automatically when its form is displayed, and saved automatically when the form is closed. For details, see How to: Create Application Settings Using the Designer.

If you want more detailed control over your settings, you can define your own custom applications settings wrapper class. This is accomplished by deriving a class from ApplicationSettingsBase, adding a property that corresponds to each setting, and applying special attributes to these properties. For details about creating wrapper classes, see Application Settings Architecture.

You can also use the Binding class to bind settings programmatically to properties on forms and controls. For more information about creating wrapper classes, see How to: Create Application Settings Using the Designer.

Tasks

Concepts

Reference