Custom Settings Providers
In the Application Settings architecture, there is a loose coupling between the applications settings wrapper class, derived from ApplicationSettingsBase, and the associated settings provider or providers, derived from SettingsProvider. This association is defined only by the SettingsProviderAttribute applied to the wrapper class or its individual properties. If a settings provider is not explicitly specified, the default provider, LocalFileSettingsProvider, 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 SettingsProvider-derived class would receive this information in its Initialize method as a parameter of type System.Collections.Specialized..::.NameValueCollection. You would then implement the GetPropertyValues method to retrieve your settings from the data store, and SetPropertyValues to save them. Your provider can use the SettingsPropertyCollection supplied to GetPropertyValues 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 ApplicationName property is an abstract property of SettingsProvider; you should program it to return the following:
Public Overrides Property ApplicationName() As String
Get
ApplicationName = System.Reflection.Assembly.GetExecutingAssembly().GetName().Name
End Get
Set(ByVal value As String)
' Do nothing.
End Set
End Property
public override string ApplicationName
{
get
{
return (System.Reflection.Assembly.GetExecutingAssembly().GetName().Name);
}
set
{
// Do nothing.
}
}
Your derived class must also implement an Initialize method that takes no arguments and returns no value. This method is not defined by SettingsProvider.
Finally, you implement IApplicationSettingsProvider 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 SettingsProviderAttribute. 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 LocalFileSettingsProvider for the rest. The following code example shows how to instruct the settings class to use your custom provider.
Imports System.Configuration
<SettingsProvider("SqlSettingsProvider")> _
Public Class CustomSettings
Inherits ApplicationSettingsBase
' Implementation goes here.
End Class
using System;
using System.Collections.Generic;
using System.Text;
using System.Configuration;
namespace ApplicationSettingsArchitectureCS
{
class CustomSettings : ApplicationSettingsBase
{
// Implementation goes here.
}
}
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.
.gif) Important Note: |
|---|
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 System.Configuration namespace, though it must at a minimum support ApplicationScopedSettingAttribute and UserScopedSettingAttribute, and should also support DefaultSettingValueAttribute. 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 ApplicationScopedSettingAttribute and UserScopedSettingAttribute to the same setting — your provider should throw an exception and cease operation.