Automatically "upgrade" user settings from previous version of app.config file?

Question

Every time I compile my app and the version number changes (I have an auto-incrementing build number), I lose the user-configured app.config settings, since they're stored in the AppData folder for a specific version. Essentially, every release of my application starts from scratch as far as user settings go.

While this is a mild annoyance in development, it raises the question as I approach deployment/release - if I use the app.config to store my user settings, will the user's personalized settings be hosed every time they install a patch that changes the version number of my app? If so, is there an easy way to "upgrade" the settings from the previous release? I know that using HKCU in the registry is another option, but I like the ease of the My.Settings namespace, and I'd like to stay with app.config.

Another SO question asks something similar, though the answer doesn't seem that clear. Will setting my MSI so it asks the user to upgrade be enough to preserve these user-level settings?

Notepaper

Answer 1

Have you looked at ApplicationSettingsBase.Upgrade()? It allows the settings to be upgraded from a previous version using the following call:

My.Settings.Upgrade()

Atrophied

That's exactly the behavior I was looking for - it fetches the most recent copy of the settings and loads those. Also worth noting is the ApplicationSettingsBase.GetPreviousVersion method, which you can use to load a single setting from a previous version. Thanks! – Notepaper

Answer 2

Not sure why but neither the upgrade command or the get previous version seems to work for me. What could I be doing wrong? Do I need to call a refresh command or something. I am doing this on form load, should it be an application event?

UPDATE

Found out why, it seems it does not work when you use a 4 digit major version number. I was using the year 2012 as the major version number. I have changed that to 12 and it works like a charm, though is no not millenium compliant. Still I got 88 years before I need to start worrying about that!

Winona

Answer 3

Have you considered ClickOnce deployment? This topic is then covered in depth. IMO, ClickOnce is much easier both for the developer and the user.

Quinquennium

ClickOnce is great until it doesn't work, and then debugging it is nearly impossible. We used to use it, and replaced it with a "launcher" type program of our own because there were too many things which could go wrong out of our control and without sufficient logging which left the user sol. – Homocyclic