7

.NET applications developed using Visual Studio have an easy way to store and recover user settings. You can add the default value of a setting in a special class and have read/write access to it at run time through Properties.Settings.Default.SettingName.

Some applications have use for values to be remembered between sessions, which will have to be stored somewhere else than in memory. One possibility would be to create a file of a specific format (XML, JSON, ini, or something else) in the user's data directory and use it for such values.
The "settings" described above are essentially such a file, but the values that need to be remembered might not technically be settings. One example is the timestamp of the last time a certain function was performed.

One might argue against storing such a value in Properties.Settings as it is not a setting (i.e. user preference) and therefore the namespace's name would cause confusion.
Is there, however, a practical reason not to use Properties.Settings to store such a value?

George T
  • 295
  • 1
  • 6
  • 2
    Slippery slope argument - it may be OK for one value, but one could lead to two could lead to thirty. – Dan Pichelman Jun 08 '16 at 14:01
  • 1
    It is really common for application frameworks to have some sort of "settings" or "preferences" system similar to this one, and AFAIK everyone uses them as a simple key-value store for data such as recent files, last launch, session tokens, etc etc. – Darkhogg Jun 08 '16 at 14:16
  • 3
    Storing things where other programmers expect them to be *is a practical reason.* That said, if I had a place where I needed to store a single timestamp, User Settings is probably where I would put it. – Robert Harvey Jun 08 '16 at 14:21
  • 2
    Or application settings if it needs to be across all users... – Adam Zuckerman Jun 08 '16 at 15:07

2 Answers2

2

You wrote

Some applications have use for values to be remembered between sessions

well, that is true whenever you have to persist data

would be to create a file of a specific format (XML, JSON, ini, or something else) in the user's data directory and use it for such values. [...] One example is the timestamp of the last time a certain function was performed.

So you are talking about data which has to be persisted per user (maybe also per machine), and where it is not "mission critical" if they got lost because of a missing backup. That is IMHO exactly the use case for Properties.Settings

the values that need to be remembered might not technically be settings.

But why not? Because you associate something different with that term? I would not be so picky about the term - just because Microsoft choose the name Settings for that class, and did not call the class SettingsAndOtherUserPersistentData should not hinder you to use the mechanism for your purpose, as long as it fits to the scenario I scetched above.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
1

Properties.Settings are stored for the user on the machine. If you want the settings to be common to all users and/or all machines, this method would not do. You also may want to have input parameters for the application that steer its behavior rather than preferences, and have several sets of them ready to be used in different senarios. For this, Properties.Settings would not be right or usable either since there is just one hidden set that cannot be changed externally in an easy and obvious manner (you can not start the application instructing it to use a particular set). You could however load input parameters from Properties.Settings once the application is up.

Properties.Settings is a quick way to persist some stuff but will soon fall apart as your application grows due to lack of flexibility and vagueness regarding the purpose of the data stored. You would want to separate input from personal preferences from administrative preferences from configuration from environment settings from whatever further applies to your software. And each may have to be maintained separately by different people and be retrieved from different sources (database, registry, xml document, environment variables).

Martin Maat
  • 18,218
  • 3
  • 30
  • 57