Settings.Default.Upgrade() does not keep current settings

Question

I have a WPF application that uses the built-in Settings functionality. When I release a new version of the application, I increase the assembly version and execute the following code at application start:

if (Settings.Default.IsSettingsUpgradeRequired) //this defaults to true when a new version of this software has been released
            {
                Settings.Default.Upgrade(); //upgrade the settings to the newer version
                Settings.Default.Reload();
                Settings.Default.IsSettingsUpgradeRequired = false;
                Settings.Default.LastSettingsUpdate = DateTime.Now.ToShortDateString() + " " + DateTime.Now.ToShortTimeString();
                Settings.Default.Save();
            }

The problem is that the previous settings are not maintained. Instead, a new folder under \AppData\Local\ is created each time a new version comes up. Thus, the default settings are used instead of those of the previous version. I know that, under normal circumstances, there should be ONE folder that contains many sub-folders with the application's version as name. Instead, I have MANY folders each containing only one folder with the application's version as name. The folder structure in Local\ looks like this:

• myApp.exe_Url_5s2axp5sywfyhblm3201qetpqnmwnvsc
• myApp.exe_Url_ft4ih1ze0qsz5abu11t334omxo1431c0
• myApp.exe_Url_glsc2d3cjmswry2bxebb53jndfptav1x
• myApp.exe_Url_qngn1rqmbfyy42fdgpmc3ystsaknuxnv
• myApp.exe_Url_vqn0ogftrchl1fild5fe34hmijvmd2zr

So how do I stop the system to create so many folders and make it only use one folder per application so that I can properly upgrade my settings?

Edit: another thing I noticed today is that if I change the location of the application's folder (lets say move it from desktop to C:\myApp), the application creates a new settings folder when first started. Why does the system not recognize it as the same application?

Answer 1

I finally got it to work. I don't know the cause for the desrcibed behavior, but one of these 2 things fixed it:

• Added the default manifest file and changed the "assemblyIdentity" node (the "version" attribute does not seem to have an effect on the Settings)
• Activated the signing feature of Visual Studio (Project properties --> Signing)