How to persist changes in a .settings/.config file across a file version change?

Question

I have created an application that uses settings.settings to store some user specific settings (scope=User). Settings are loaded correctly on startup, changed during use and saved correctly for next launch. This cycle appears to have no problems.

The problem arises when I update the assembly and file versions for a new build. The settings are no longer loaded on startup (instead the default values are used). It also appears that a config file saved from version 1.1 will persist even if version 1.2 is launched and a NEW config file is generated and saved too (i.e. you can relaunch version 1.1 and the config file will be the config file that was saved from that version).

So it appears that the settings are specific to the version of the assembly and/or file. It is also worth noting that between version 1.1 and version 1.2 there were no changes to the settings.settings file or anything else for that matter (i.e. the only change I made between these different builds was modifying the version numbers).

Is there a way to persist these settings across version changes?

Nitpicking

Retaining settings between upgrades can be another challenge when using the .Net Settings class. The link at the start of this post has the answer. – Acerb

I posted a possible solution in this thread. Hope that helps! – Garratt

I've posted a possible solution in the following thread: https://mcmap.net/q/145443/-keep-user-39-s-settings-after-altering-assembly-file-version Hope that helps! – Garratt

Answer 1

Markus Olsson has already given a pretty good answer here.

Essentially you will need to use the ApplicationSettingsBase.Upgrade() method.

Tapia

Thank you for the information!! It is now compiled, tested, working as expected and now fully integrated into the project!! I will award you the bounty when I can (apparently I have to wait to accept this answer - should be later today or tomorrow). :D – Nitpicking

Answer 2

A few clarifications:

You have to call the Upgrade method of ApplicationSettingsBase derived class (that is normally called Settings and is created for you by Visual Studio):

Properties.Settings.Default.Upgrade();

When/where to call the Upgrade method? There is a simple trick you can apply: define a user setting called UpgradeRequired (example) as bool (the easiest way is through IDE). Make sure its default value is true.

Insert this code snipped at the start of the application:

  if (Properties.Settings.Default.UpgradeRequired)
  {
      Properties.Settings.Default.Upgrade();
      Properties.Settings.Default.UpgradeRequired = false;
      Properties.Settings.Default.Save();
  }

So the Upgrade method will be called only after the version changes and only one time (since you disable further upgrades by setting UpgradeRequired = false until a version change - when the property regains default value of true).

Lemniscus

Instead of / in addition to UpgradeRequired, I would store the App's version as a Setting. That allows you to perform custom upgrade conversions (i.e., of an invalid value / valid value to other than -the latest version's default / -same value). You can have code that converts each applicable version needing conversion to the next lowest version that requires it and daisy chain the code together thereby: a) reducing complexity of the latest version's conversion code and b) allowing for potential retiring of old conversion code. – Poundfoolish

Answer 3

I hope someone else has a better answer. I had this question a few years ago, and the only solution I could find (which did work) was to use my own mechanism for storing settings, rather than the default built-in .NET way.

Prescript

Thanks for chipping in your experience... I'm blown away I don't have an answer right now that is straight forward and simple (both through SO and me trying to answer this myself in the docs). It's leading me to believe that it isn't possible... which is crazy for what seems like a great time saving feature to be made almost completely useless for the vast majority of projects. – Nitpicking