This is an issue that only happens for some users. Whenever I release a new version of my app in Marketplace I get emails from users saying that all the settings in the app are lost.
I can't reproduce this myself and I have no code that can wipe the IsolatedStorage.
Would be great if anyone out there had a clue on what might be causing this.
Update: Not sure if the following applies to WP7 apps - I'll leave it here just in case. I have only tried this for normal apps.
You will need to "upgrade" the old settings file.
You also need to know when you need to do this (i.e. only when a new version is installed).
To know when you need to upgrade settings, add a boolean called (say) NeedSettingsUpgrade to your settings, and default it to true.
Then call the following function somewhere near the start of Main():
/// <summary>Upgrades the application settings, if required.</summary>
private static void upgradeApplicationSettingsIfNecessary()
{
// Application settings are stored in a subfolder named after the full #.#.#.# version number of the program. This means that when a new version of the program is installed, the old settings will not be available.
// Fortunately, there's a method called Upgrade() that you can call to upgrade the settings from the old to the new folder.
// We control when to do this by having a boolean setting called 'NeedSettingsUpgrade' which is defaulted to true. Therefore, the first time a new version of this program is run, it will have its default value of true.
// This will cause the code below to call "Upgrade()" which copies the old settings to the new.
// It then sets "NeedSettingsUpgrade" to false so the upgrade won't be done the next time.
if (Settings.Default.NeedSettingsUpgrade)
{
Settings.Default.Upgrade();
Settings.Default.NeedSettingsUpgrade = false;
}
}
Note: You will of course need to call Settings.Default.Save()
before your program exits, otherwise the settings change won't be persisted.
My approach to this has been to use the assembly version number as the trigger for the upgrade. On first run it save settings in the format required for v1.0 and the assembly version number 1.0.0.0. When an upgrade occurs it compares the saved setting number (1.0.0.0) with the upgraded assembly number 1.1.0.0 and decides that an upgrade is needed.
I discovered that doing a redeploy for visual studio did not guarentee to do an upgrade, sometimes it did an uninstall, reinstall which was not as good. So I changed to using Windows Phone Powertools to test my "upgrade" path as it seems to reliably do upgrades.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With