Client Settings - Part 3
RichB has some interesting questions in his comments about my earlier post on the client settings feature. I thought it might be worth a separate post to answer them.
I don't have the CTP available, but from the documentation it appears that ApplicationSettingsBase can read and write to a collection of providers. I can understand the writing to multiple providers (saving the same values into multiple locations) but how does it read the same values from multiple locations.
Yes, a settings class can talk to multiple providers, but each setting (or property) in it is associated with a single provider. This just means that you can have different providers for different settings in a settings class.
I also hope you have a good "story" for plug-in based applications. For example, Lutz Roeder's Reflector and Nikhil's Web Matrix are both heavily pluggable. Is there a prescribed way for each plug-in/component to obtain and save configuration information to the same store?
Yes, we have a story for this scenario. There is an interface called IPersistComponentSettings that any component can implement to save its own settings when hosted in an application. For example, the ToolStrip control implements this. Someone using the ToolStrip in their app can just set a property called SaveSettings to true and the ToolStrip will save/restore settings automatically without the user having to set anything up.
I'm also a bit hazy on Setting Groups. I've noticed the SettingsGroupNameAttribute - but am not entirely clear on how it's meant to be used.
Usually, the settings class name is used to identify your settings in the store. If you want them stored with a different name or share settings with some other class, you can use the SettingsGroupNameAttribute to rename/redirect your settings.
Finally, do you have generic methods for loading from the store to prevent boxing?
No, but that's a good suggestion. We will consider doing this.
