--- title: "Application Settings Architecture" ms.date: "03/30/2017" dev_langs: - "csharp" - "vb" helpviewer_keywords: - "application settings [Windows Forms], architecture" ms.assetid: c8eb2ad0-fac6-4ea2-9140-675a4a44d562 --- # Application Settings Architecture This topic describes how the Application Settings architecture works, and explores advanced features of the architecture, such as grouped settings and settings keys. The application settings architecture supports defining strongly typed settings with either application or user scope, and persisting the settings between application sessions. The architecture provides a default persistence engine for saving settings to and loading them from the local file system. The architecture also defines interfaces for supplying a custom persistence engine. Interfaces are provided that enable custom components to persist their own settings when they are hosted in an application. By using settings keys, components can keep settings for multiple instances of the component separate. ## Defining Settings The application settings architecture is used within both ASP.NET and Windows Forms, and it contains a number of base classes that are shared across both environments. The most important is , which provides access to settings through a collection, and provides low-level methods for loading and saving settings. Each environment implements its own class derived from to provide additional settings functionality for that environment. In a Windows Forms-based application, all application settings must be defined on a class derived from the class, which adds the following functionality to the base class: - Higher-level loading and saving operations - Support for user-scoped settings - Reverting a user's settings to the predefined defaults - Upgrading settings from a previous application version - Validating settings, either before they are changed or before they are saved The settings can be described using a number of attributes defined within the namespace; these are described in [Application Settings Attributes](application-settings-attributes.md). When you define a setting, you must apply it with either or , which describes whether the setting applies to the entire application or just to the current user. The following code example defines a custom settings class with a single setting, `BackgroundColor`. [!code-csharp[ApplicationSettings.Create#1](~/samples/snippets/csharp/VS_Snippets_Winforms/ApplicationSettings.Create/CS/MyAppSettings.cs#1)] [!code-vb[ApplicationSettings.Create#1](~/samples/snippets/visualbasic/VS_Snippets_Winforms/ApplicationSettings.Create/VB/MyAppSettings.vb#1)] ## Settings Persistence The class does not itself persist or load settings; this job falls to the settings provider, a class that derives from . If a derived class of does not specify a settings provider through the , then the default provider, , is used. The configuration system that was originally released with the .NET Framework supports providing static application configuration data through either the local computer's machine.config file or within an `app.`exe.config file that you deploy with your application. The class expands this native support in the following ways: - Application-scoped settings can be stored in either the machine.config or `app.`exe.config files. Machine.config is always read-only, while `app`.exe.config is restricted by security considerations to read-only for most applications. - User-scoped settings can be stored in `app`.exe.config files, in which case they are treated as static defaults. - Non-default user-scoped settings are stored in a new file, *user*.config, where *user* is the user name of the person currently executing the application. You can specify a default for a user-scoped setting with . Because user-scoped settings often change during application execution, `user`.config is always read/write. All three configuration files store settings in XML format. The top-level XML element for application-scoped settings is ``, while `` is used for user-scoped settings. An `app`.exe.config file which contains both application-scoped settings and defaults for user-scoped settings would look like this: ```xml
Default False Form1 595, 536 ``` For a definition of the elements within the application settings section of a configuration file, see [Application Settings Schema](/dotnet/framework/configure-apps/file-schema/application-settings-schema). ### Settings Bindings Application settings uses the Windows Forms data binding architecture to provide two-way communication of settings updates between the settings object and components. If you use Visual Studio to create application settings and assign them to component properties, these bindings are generated automatically. You can only bind an application setting to a component that supports the interface. Also, the component must implement a change event for a specific bound property, or notify application settings that the property has changed through the interface. If the component does not implement and you are binding through Visual Studio, the bound properties will be set the first time, but will not update. If the component implements but does not support property change notifications, the binding will not update in the settings file when the property is changed. Some Windows Forms components, such as , do not support settings bindings. ### Settings Serialization When must save settings to disk, it performs the following actions: 1. Uses reflection to examine all of the properties defined on your derived class, finding those that are applied with either or . 2. Serializes the property to disk. It first attempts to call the or on the type's associated . If this does not succeed, it uses XML serialization instead. 3. Determines which settings go in which files, based on the setting's attribute. If you implement your own settings class, you can use the to mark a setting for either binary or custom serialization using the enumeration. For more information on creating your own settings class in code, see [How to: Create Application Settings](how-to-create-application-settings.md). ### Settings File Locations The location of the `app`.exe.config and *user*.config files will differ based on how the application is installed. For a Windows Forms-based application copied onto the local computer, `app`.exe.config will reside in the same directory as the base directory of the application's main executable file, and *user*.config will reside in the location specified by the property. For an application installed by means of ClickOnce, both of these files will reside in the ClickOnce Data Directory underneath %InstallRoot%\Documents and Settings\\*username*\Local Settings. The storage location of these files is slightly different if a user has enabled roaming profiles, which enables a user to define different Windows and application settings when they are using other computers within a domain. In that case, both ClickOnce applications and non-ClickOnce applications will have their `app`.exe.config and *user*.config files stored under %InstallRoot%\Documents and Settings\\*username*\Application Data. For more information about how the Application Settings feature works with the new deployment technology, see [ClickOnce and Application Settings](/visualstudio/deployment/clickonce-and-application-settings). For more information about the ClickOnce Data Directory, see [Accessing Local and Remote Data in ClickOnce Applications](/visualstudio/deployment/accessing-local-and-remote-data-in-clickonce-applications). ## Application Settings and Security Application settings are designed to work in partial trust, a restricted environment that is the default for Windows Forms applications hosted over the Internet or an intranet. No special permissions beyond partial trust are needed to use application settings with the default settings provider. When application settings are used in a ClickOnce application, the `user`.config file is stored in the ClickOnce data directory. The size of the application's `user`.config file cannot exceed the data directory quota set by ClickOnce. For more information, see [ClickOnce and Application Settings](/visualstudio/deployment/clickonce-and-application-settings). ## Custom Settings Providers In the Application Settings architecture, there is a loose coupling between the applications settings wrapper class, derived from , and the associated settings provider or providers, derived from . This association is defined only by the applied to the wrapper class or its individual properties. If a settings provider is not explicitly specified, the default provider, , is used. As a result, this architecture supports creating and using custom settings providers. For example, suppose that you want to develop and use `SqlSettingsProvider`, a provider that will store all settings data in a Microsoft SQL Server database. Your -derived class would receive this information in its `Initialize` method as a parameter of type . You would then implement the method to retrieve your settings from the data store, and to save them. Your provider can use the supplied to to determine the property's name, type, and scope, as well as any other settings attributes defined for that property. Your provider will need to implement one property and one method whose implementations may not be obvious. The property is an abstract property of ; you should program it to return the following: [!code-csharp[ApplicationSettings.Architecture#2](~/samples/snippets/csharp/VS_Snippets_Winforms/ApplicationSettings.Architecture/CS/DummyClass.cs#2)] [!code-vb[ApplicationSettings.Architecture#2](~/samples/snippets/visualbasic/VS_Snippets_Winforms/ApplicationSettings.Architecture/VB/DummyProviderClass.vb#2)] Your derived class must also implement an `Initialize` method that takes no arguments and returns no value. This method is not defined by . Finally, you implement on your provider to provide support for refreshing settings, reverting settings to their defaults, and upgrading settings from one application version to another. Once you have implemented and compiled your provider, you need to instruct your settings class to use this provider instead of the default. You accomplish this through the . If applied to an entire settings class, the provider is used for each setting that the class defines; if applied to individual settings, Application Settings architecture uses that provider for those settings only, and uses for the rest. The following code example shows how to instruct the settings class to use your custom provider. [!code-csharp[ApplicationSettings.Architecture#1](~/samples/snippets/csharp/VS_Snippets_Winforms/ApplicationSettings.Architecture/CS/DummyClass.cs#1)] [!code-vb[ApplicationSettings.Architecture#1](~/samples/snippets/visualbasic/VS_Snippets_Winforms/ApplicationSettings.Architecture/VB/DummyProviderClass.vb#1)] A provider may be called from multiple threads simultaneously, but it will always write to the same storage location; therefore, the Application Settings architecture will only ever instantiate a single instance of your provider class. > [!IMPORTANT] > You should ensure that your provider is thread-safe, and only allows one thread at a time to write to the configuration files. Your provider does not need to support all of the settings attributes defined in the namespace, though it must at a minimum support and , and should also support . For those attributes that it does not support, your provider should just fail without notification; it should not throw an exception. If the settings class uses an invalid combination of attributes, however — such as applying and to the same setting — your provider should throw an exception and cease operation. ## See also - - - - [Application Settings Overview](application-settings-overview.md) - [Application Settings for Custom Controls](application-settings-for-custom-controls.md) - [ClickOnce and Application Settings](/visualstudio/deployment/clickonce-and-application-settings) - [Application Settings Schema](/dotnet/framework/configure-apps/file-schema/application-settings-schema)