Click here to Skip to main content
13,589,335 members
Click here to Skip to main content
Add your own
alternative version


75 bookmarked
Posted 17 Oct 2007
Licenced CPOL

Creating a Custom Settings Provider

, 17 Oct 2007
Rate this:
Please Sign up or sign in to vote.
Demonstration of how to write custom settings providers.


This article demonstrates how to write a custom Settings Provider to allow you to persist your My.Settings to your own storage system. The example given creates an XML file in the application folder which is ideal for portable applications. It also includes brief details of how to implement storage onto a U3 compliant USB device.


The My.Settings functionality introduced with .NET 2.0 saves a lot of time and repeated effort for developers by providing a common, easy to use, and well thought out method of loading/saving settings. For a standard WinForms application, this works great, separating local and roaming settings automatically and storing them in the Documents and Settings\User\Local Settings\Application Data and Documents and Settings\User\Application Data folder hierarchies, respectively. But, what happens if you haven't got a typical scenario, say you want settings to be stored on a network drive, or you want them to be portable with the application so they can run off a USB device? As with most things in the .NET framework, you can override this default behaviour thankfully. In this case, it's by writing your own Settings Provider. This sounds daunting, but is actually relatively trivial. All you have to do is create a new class that inherits from SettingsProvider and provide the must override ApplicationName property which I just default to the Product Name.

Using the Code

Using a custom settings provider is simple; just include the class within your application, and when viewing the My Project/Settings page, just set the Provider property (defaults to blank) to your provider class name. Note that the Provider property is set for each setting individually; that way, you could keep some items under the default .NET provider model but override a few critical ones to travel with you using this portable provider.

The screenshot below shows exactly where to change this:

Screenshot - CustomSettingsProvider1.jpg

By default, the roaming property is set to false, which for the portable settings provider will mean that the setting is machine specific. For settings like window size/location, this is desired, but for settings you want to be used regardless of machine (in this example, the UserWord), you should set this to true.

Other than that, handle the settings exactly as you would normally do. In the example app, we just get and set them on our Form Load and Closing events.

When you run the application, it tries to load the settings from an XML file named applicationtitle.settings. Since this does not exist to start with, it uses the default values. Upon exiting the application, the settings file is created. If you have a look at it (in the project's bin/debug folder), you'll see it has the following format;

<?xml version="1.0" encoding="utf-8"?>
    <WindowSize>300, 100</WindowSize>
    <WindowLocation>100, 100</WindowLocation>
    <WindowSize>300, 200</WindowSize>
    <WindowLocation>300, 300</WindowLocation>

Notice how the settings that have a roaming value of false are enclosed within an element for the current PC name, whilst the roaming setting of UserWord is at the Settings node level, meaning it is used regardless of the PC you are using.

Also included is a U3 specific settings provider. This inherits from PortableSettingsProvider, overriding the GetAppSettingsPath function which, in this case, tries to retrieve a path from an environment variable. If you're happy with the storing of settings within an XML file but just want to change the location (perhaps a common network mapping), then you can use this inheritance technique as well.

Points of Interest

The real guts of the Settings Provider happen in the GetPropertyValues and SetPropertyValues functions. These pass in a collection object of all properties required to be got/set for this provider, which we just iterate round, loading or saving them to our XML document. I have implemented a SettingsXML property which either loads or creates a new XML document with the required root node.

The final point of interest is the IsRoaming function. This looks through the attributes collection of the objects on the property for a type of SettingsManageabilityAttribute. This attribute being present indicates that the IsRoaming property is set to true.


  • 18 October 2007 - Initial article.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Web Developer
United Kingdom United Kingdom
A general purpose analyst programmer working in a small development team for a company in the city.

VB has always been my passion and I code both Win forms and web based systems for both work and fun.

You may also be interested in...


Comments and Discussions

Questionmore than one setting provider? Pin
Rejditsch11-Nov-09 1:17
memberRejditsch11-Nov-09 1:17 
AnswerRe: more than one setting provider? Pin
Rejditsch11-Nov-09 2:46
memberRejditsch11-Nov-09 2:46 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Cookies | Terms of Use | Mobile
Web03 | 2.8.180615.1 | Last Updated 18 Oct 2007
Article Copyright 2007 by CodeChimp
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid