Are app settings reliable?
I am wondering if the application settings are reliable for storing values?
I was thinking about saving my application XML file there, so when I run the program, it knows where the XML file is, even if the path was changed during the latest version.
-
Is there a chance the application options might forget / delete the file path value? Or maybe everything related to this?
-
Are there any better ways to achieve my goal?
source to share
Yes, they are reliable. And they will do it very well because they will take into account OS-specific conventions and OS user profiles. So I would say this is the recommended practice.
There is a small catch: a later version of your application may look for settings for its own version, even if there are settings for an older version. In this case, you will need to make sure that the application carries over the old settings and converts them to its own, instead of ignoring them. It's pretty easy.
There is a big catch: moving an application to a different location on disk will make it think of itself as a new instance and create its own settings. If you want to avoid this behavior, you will have to consider creating a heavily named assembly (which I find inconvenient to say the least).
source to share
As mentioned, yes App Settings are reliable and well explained by Chatzigiannak. However, I want to share with you some thoughts regarding the application settings that happened here.
We are currently using an external file and loading it into the web.config file. Pretty simple:
<appSettings file="DIR\Configuration\AppSettings.config"></appSettings>
This code is distributed across 15 of our websites. The file looks something like this:
<?xml version="1.0"?>
<appSettings>
<add key="CacheEnabled" value="0"/>
...
</appSettings>
Then we realized that this file is growing and now it has 600 keys, cool isn't it? But this is not the worst part, each server must have its own configuration, so we distribute this file through 7 servers ... And some of them have different keys ... Imagine you need to change the path to one specific key, on all servers ... We created a monster =)
After reviewing the code, we decided to save it to the database. A simple table with the IP address of the machine as the key and the JSON key value as the document. Certainly not 600 columns.
When I told my team that I was doing this, one guy said, "Are you crazy? You will have to change 1k of this code":
ConfigurationManager.AppSettings["KEYNAME"];
Indeed, yes, I had to change it, but I thought about it in a simple way by creating my own ConfigurationManager which has an IndexValueCollection AppSettings inside:
public static class ScopeManager
{
private static NameValueCollection _appSettings;
public static NameValueCollection AppSettings
{
get
{
if (_appSettings.IsNull())
{
//GET FROM DATABASE, CACHE OR SOMEWHERE ELSE
}
return _appSettings;
}
}
}
And the changes became:
ScopeManager.AppSettings["KEYNAME"];
I don't think we have invented the wheel. But we've done a lot better with a lot of keys / websites / servers ... It seems like it really is the real world.
source to share