Home/ Questions/Q 838007
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T05:14:04+00:00

I’m looking at some code that uses the .NET System.Configuration.SettingsProvider and ApplicationSettingsBase to handle

  • 0

I’m looking at some code that uses the .NET System.Configuration.SettingsProvider and ApplicationSettingsBase to handle configuration.

We have a class that derives from SettingsProvider that uses a database as the data store, and then we have other settings classes that inherit from ApplicationSettingsBase, and have the [SettingsProvider(typeof(MySettingsProvider))] attribute.

The problem is that we’re using these settings classes in multiple applications, but they seem to permanently cache the configuration values, the first time they are loaded. The issue is that if a setting is changed in one application, the other applications will not get the setting until the next restart, because they are cached everywhere.

My question is: is there a way to force the SettingsProvider implementation, or the classes derived from ApplicationSettingsBase to not cache values, and re-query the datastore every time the setting is accessed? A valid answer might be that these classes were not intended to be used in multi-application environments…

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Settings objects based on ApplicationSettingsBase only interact with the persistence mechanism/SettingsProvider on instantiation, Save or Reload operations. The rest of the time, it’s just working off the hashtables in the settings object.

    There’s a few ways to get the behaviour that you want.

    First, you could implement those non-cacheable properties manually, rather than rely on the persistence mechanism. You can do this in a partial class that is a companion to your normal vs.net generated settings class. If you implemented your own settings class, you don’t need the partial class, and you can just tack on the property. The drawback of this approach is that every read on that setting, will incur a db hit.

    Alternatively, if you need read caching, yet allow for change across applications. In ApplicationSetttingsBase.Save, which you can override, you could use a publish/subscriber mechanism that allows you to notify all the subscribers to refresh their through ApplicationSetttingsBase.Reload.
    This is much more involved, and depending on requirements, you may need to worry about keeping the state of your settings objects consistent.

    • 0