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?

Hollie

I don't use Reload() in the code I use to update settings, and it works OK. Try removing it. – Cocainize

Already tried, doesn't change anything. The problem is that the system creates a new application folder for each software version, as If it doesn't recognize that it's the same application... – Hollie

Maybe it has something to do with having/not having a manifest file? Or do I maybe have to sign the application? – Hollie

How did you add IsSettingsUpgradeRequired? – Diopside

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)

Hollie

What did you change in assemblyIdentity? – Evie

@mrid: Nothing special, just set it like this: <assemblyIdentity version="1.0.2.2" name="MyCompany.ApplicationName"/> – Hollie

Answer 2

Activated signing will ensure that only one folder is generated in

\AppData\Local\

also necessary to execute Settings.Default.Upgrade() after the application is launched

Nyctalopia

Answer 3

Project -> Properties -> Application -> Manifest = Embed manifest with default settings

Butene

Answer 4

@cleo Thanks for solution. Signing fixed the issue. The folder name no longer changes.

\AppData\Local\MyAppName.exe_StrongName_iyq1qat10dlrezghdzsmthpr49hlodkj

Contention

Please don't add "thank you" as an answer. Instead, vote up the answers that you find helpful. - From Review – Manganate

Answer 5

I'm using .NET6 in 2022 and just adding this during app start worked for me:

Settings.Default.Upgrade();

Eraste

Answer 6

A bit late, but for completeness:

I'm not sure how previous versions have handled it, but when I migrated my Winforms app to .NET 8, Settings.Default.Upgrage() was broken, and none of the things mentioned in other answers have helped.

In my case, the seeming culprit was the fact that the app used both Local and Roaming settings, so 2 user.config files were created in different folders. This somehow was interfering with settings upgrade.

After I changed all settings (both User- and Application-level) to Local, an app.config file was silently added to the project by Visual Studio, and the settings started to upgrade correctly. I'm still technically unsure whether it was the lack of app.config file, or the presence of Roaming settings, but either way it fixed them.

HTH

Buccal