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:
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;
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
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.