One of the polished areas of .Net Framework 2.0 is manipulation with Application/User settings in WinForms applications. You can store almost anything in appropriate app.config or user.config file, and to manipulate with those settings with ease – wrapper class created around Settings allows you to use settings as just another field in your code.
But, what about of upgrade existing settings once when you create new version of the application?
That is supported via Upgrade() method:
Settings.Default.Upgrade();
Settings.Default.Save();
You can add one user bool setting (for example UpgradeSettings) with default value True, which will be a flag if upgrade is carried out; code can be:
if (Settings.Default.UpgradeSettings)
{
Settings.Default.Upgrade();
Settings.Default.UpgradeSettings = false;
Settings.Default.Save();
}
Suppose that your application is simple little application, not a Click-Once or even distributed with installer – just archive which users can download, unpack and start using.
If you new version picks user settings folder from previous one, all is fine – Upgrade() method will find previous version and upgrade them:
Suppose that this is true:
- both versions are either signed or not (if you do signing of assembly between versions, Upgrade will fail)
- both versions are either Click-Once applications or not (for the same reasons)
In theory, all is fine and Upgrade should do the job. But, what if all above is fulfilled and that you still have different user settings folder:
What can be reason that same application creates completely different user settings folder? This situation happened to me. After couple of hours, I could not determine reason, so I pulled out heavy tools – Reflector.
If you start tracking .Upgrade(), it goes to: ApplicationSettingsBase.Upgrade which simply calls IApplicationSettingsProvider.Upgrade for each provider present. For simple WinForms application, appropriate provider is LocalFileSettingsProvider. After some more thorough analysis, internal method for determining folder of settings store is:
System.Configuration.ClientConfigPaths
One of elements in determining local store for user settings was hashed value derived from Evidences for given assembly.
It turns out that one of Evidence elements for non-signed assemblies is path from where assembly/application is launched!.
To summarize: in order for Upgrade() of settings succeed, your new version of application should be deployed in the exact same folder where previous version is found; otherwise, Upgrade() will fail (or at least, it won’t do what you expected 🙂 )