This is a review of the application settings architecture from MSDN. A setting specified in a custom settings file and embedded as a resource in the assembly is resolved when called from a console application but not from a test project. Hence this review is for a quick recap of the underlying mechanism.
Settings are strongly typed with either application scope or user scope. The default store for the settings is the local file based system. There is support for adding custom stores by way of SettingsProvider attribute.
SettingsBase provides access to settings through a collection. ApplicationSettingsBase adds higher level loading and saving operations, support for user-scoped settings, reverting a user's settings to the predefined defaults, upgrading settings from a previous application and validating.
Settings use the windows form data binding architecture to provide two-way communication of settings updates between the settings object and components. Embedded resources are pulled up with Reflection.
Settings are strongly typed with either application scope or user scope. The default store for the settings is the local file based system. There is support for adding custom stores by way of SettingsProvider attribute.
SettingsBase provides access to settings through a collection. ApplicationSettingsBase adds higher level loading and saving operations, support for user-scoped settings, reverting a user's settings to the predefined defaults, upgrading settings from a previous application and validating.
Settings use the windows form data binding architecture to provide two-way communication of settings updates between the settings object and components. Embedded resources are pulled up with Reflection.
No comments:
Post a Comment