Client Settings in Whidbey

So, I decided to experiment with SettingsProviders et al. in Whidbey to see what these things are for. Initially, I found a gem of a class called “ConfigHelper”. But, it turned out to be one of those classes that I cannot touch. It had some really neat functionality. Oh, well.

After poking around, I found that in Whidbey, creating type safe application settings is very simple (in theory, at least). In this blog, Raghavendra Prabhu talked about how client settings are dealt with in Whidbey. So, I had to find out if it was as easy as it is said to be.

So, I started creating a new Console application Project in C#. I went into the settings section in the properties (just double-click the properties folder in the Solution explorer).

Here, you would have to edit the settings to add any new properties that you would like. You can even Browse to a custom class of your own to map. It seems that you need to have already compiled that otherwise browse wont find your class. There are some quirks to this editor. But, I think it will be pretty cool once it all comes together. Once that is done, you can click on “View code” for a partial class which allows you to handle certain events such as values changing and values being saved.  They are created as Settings_user.cs class.  If you want to see the remaining code, you need to go into “Properties” directory which has a Settings.cs class.

IDE creates it so that the Settnigs class will be within a namespace of the that is <main project namespace>.Properties .

ApplicationSettingsBase contains the different base implementations for Save,Reload, Reset etc. methods that allow you to either explicitly ( on in case windows forms in Application Settings, implicitly) save the data upon close and reload it when started. [This stuff did not work in Beta 1 as is.]

Since these things did not work the way I expected, I had to play around and find a way to get something to save. So, I wrote a provider of my own. Please note that this is not real provider. No exception handlers/error condition handlers anything. For that matter, I don’t care about some of the settings such as SerializeAs enumeration. And The serialized data is unreadable.

With that in mind, here is the stuff I wrote.

A INI file based settings provider for windows application

This is a simple implementation of a INI based settings provider. You can use this by tacking

[System.Configuration.SettingsProvider("IniSettings.IniProvider,IniProvider")]to your “settings” class generated by Whidbey. I have not found a way to do this through UI. After this is done, all requests for serialization go through my implementation of the settings.

I derived my class off of LocalFileSettingsProvider since it provides something (I have not tried yet) which makes it work correctly. If I directly derived from SettingsProvider, it was not getting called.

There are three methods within the class that always get called.

1. public override void Initialize(string name, System.Collections.Specialized.NameValueCollection config): This is the method that is called in the beginning by the runtime to initialize your provider. It gives you a NameValueCollection of configuration parameters that might have been setup in configuration file.
2. public override SettingsPropertyValueCollection GetPropertyValues(SettingsContext context, SettingsPropertyCollection ppc):  This method is called during the initialization of the Settings object before you are about to access anything from it.  You normally don’t call this directly. You will just use the ApplicationSettingsBase based class’s indexer to access the settings you are interested in and it in turn would have initialized and gotten these values for you. This method is also called if you call Reload.
3. public override void SetPropertyValues(SettingsContext context, SettingsPropertyValueCollection ppvc): This is the method used in order to allow the settings provider class to save the data that is relevant to its context. This is called when an application is terminating in case of a windows form, and can also be called by explicitly calling Save on the ApplicationSettingsBase class.

I have not yet figured out all the nuances of SettingsContext class yet. I think I might need a bit of a time with this.

I used INIWrapper class that was published here.

You can download the provider and testing code here.

It is pretty interesting to watch the different calls in order to setup and teardown the provider for an object. If you download the code, you will see that it is pretty easy to do this for your projects if you want to setup a different location to serialize the data/to and from.

Things I gleaned:

1. You can potentially save/reload any type as long as they are serializable. [Note that my provider does not care about the SerializeAs so it will always be URLencoded/HTMLEncoded XML]
2. It feels a bit over-engineered. This probably is a pretty neat setup for Profiles and personalization but to read and write your INI files (admit it, this is essentially a glorified initialization files), this seems like an overkill. Who knows, someone might find it useful.
3. Beta 1 is still pretty flaky in the windows based code. I searched the bug database in the beta feedback center and it does mention a bug but that fix did not help me though. I have not gotten the refresh so this might have been fixed up to work better.