Using a database to store application settings

Question

I am considering ways to make our application more extensible and easier to use without modifying the web.config file (or, in our case, application.config files containing the appsettings node parameters).

One of the ways that I was thinking about is to save the application settings in a database table that has sqlcachedependancy. It means that:

• Each time a parameter is changed in the database, the cache is invalid and the parameters are retrieved again, thus updating the application in real time without the need to modify files and restart the entire application.
• We can create a custom tool that allows us to change the settings.

The end, as I see it, is that it can cause serious logical problems in this case, if you have something that checks appsetting at the beginning of the process, and then it changes halfway, you may end up unintentionally changing the process flow, because the requirement to completely restart the application is canceled.

Is there any way around this?

Is there a better way to manage the settings so that you can change them on the fly remotely for one, several or all servers at a time?

Answer 1

I think you have nailed two main players:

• either you have access to the file system and all your settings are added to many * .config files.

OR

• you don’t have access (or only very limited access) to the server file system, and you are probably better off not setting configuration settings and user settings in the database, basically leaving only the connection string to the configuration file on disk

Both approaches have their pros and cons. I tried for a long time to find a way to “materialize” the configuration section from the database field, so that I could just use the XML configuration, but was stored in the database field. Unfortunately, the entire .NET 2.0 configuration system is very "locked up" and only assumes that the data will come from files - there is no way to connect, for example. database provider to allow the configuration system to read its contents from the database field :-( Really too bad!

The only other approach I saw was the "ConfigurationService" in the sample StockTrader 2.0 application provided by Microsoft, but for my needs, it felt superfluous and like a really complex, really heavy subsystem.

Answer 2

If you refer to an external configuration file containing application settings (leaving everything else in the regular app.config), then I believe that editing only reloads these settings, this does not restart the entire application.

There is a similar question on this issue: Attached files app.config (web.config)

WRT is the problem of changing values ​​in the middle of program execution, I think you could cache values ​​locally and raise an event when they change, allowing routines to reach a suitable point before using updated values.

I think that in asp.net we kind of get it for free, because every lifecyle page is different, so the value just applies only to new page requests, and not to the middle of execution.

Edit: some more info:

Configuration changes Cause a Restarting the application domain

From MSDN :

Changes to configuration settings in Web.config files indirectly cause the application domain to restart. This behavior occurs by design. You can optionally use the configSource attribute to refer to external configuration files that do not cause a reboot when changes are made. For more information, see ConfigSource in the common attributes inherited by section elements.

Details on the ConfigurationManager class in System.Configuration are the namespace that can be used to modify configuration files programmatically (i.e., in a custom tool, if appropriate permissions to read the disk can be granted). If you adhere to the use of built-in configuration classes, I think that changing external configurations will not restart the application, but lead to events (such as the changed property ) that you could handle to make sure your code is not detected by changing the settings .

Answer 3

You can use SQLite, which will be a standalone database in a single file. Two birds with one stone?