Windows phone 8, application settings are not saved

Question

I have the following weird behavior in my Windows 8 phone, C #.

I save the setting with:

private void SaveProperty<T>(T property, string propertyName) { if (IsolatedStorageSettings.ApplicationSettings.Contains(propertyName)) IsolatedStorageSettings.ApplicationSettings[propertyName] = property; else IsolatedStorageSettings.ApplicationSettings.Add(propertyName, property); IsolatedStorageSettings.ApplicationSettings.Save(); } 

When the application starts, I can read all the settings saved in IsolatedStorageSettings.ApplicationSettings .

But when I open the application again (open it from the list of applications), IsolatedStorageSettings.ApplicationSettings -Dictionary contains the keys and values ​​of Zero ( 0 ).

Did I miss something?

I used ISETool.exe to take snapshots of the isolated storage of my application (thanks to chepene). I saw this behavior: when I wrote Settings (this means that after the SaveProperty<T>() function has completed) and the application is still working, I have Settings saved in _ApplicationSettings . This is consistent with my observation, which I can read from IsolatedStorageSettings.ApplicationSettings when the application is running. The _ApplicationSettings file also exists if it is in a tombstone or does not work (when I can access it by holding the phone’s back button and when the application is closed using the back button).

But when the application opens again (through the list of applications), the _ApplicationSettings file disappeared ...

I also see that when I write a file in IsolatedStorage with:

 SharedStorageAccessManager.CopySharedFileAsync( Windows.Storage.ApplicationData.Current.LocalFolder, fileName+"orig", Windows.Storage.NameCollisionOption.ReplaceExisting, fileID); 

and when I don’t read this file, it will disappear the next time I open the application.

By the way, to avoid confusion: I do not reinstall the application every time I open it.

If you need more information, please ask.

Any help was appreciated.

Answer 1

Thanks to quetzalcoatl, I found a solution: I save all my files in the root folder of my application. First, I read all my files (via the DataContractSerializer) and drop them into my model. Since it sometimes happens that my files are corrupted, I delete every file that throws a SerialzationException . But when I read every file, and since _ApplicationSettings not applicable to my model, I automatically delete _ApplicationSettings . Therefore, I found out that ApplicationSettings is just a file in the root folder that I am allowed to read and delete. So the quintessence is to never write to the root folder.

Answer 2

With AppSettings, I saw something similar on WP7 / 7.5, but this only happened when my property value type was a class that was not known to the serializer.

Are you sure that there were no exceptions:

• during save
• during App Exit (as the application may reset at this point)
• for the time when the application loads the settings for the first time after launch?

Please note that this does not have to mean an application crash. I mean, any exceptions, those that are internally disabled or handled by the user. Check the VisualStudio output panel for the "first chance exceptions" log. If any I / O or security or serialization error occurs, then investigate it. If I remember well, there is even a whole set of isolated storage exceptions that are easily caught from the debug / exceptions menu.

However, the problems that I had with unknown or non-serializable types do not explain at all why your extra files without binding will evaporate.

Another thought: maybe some additional tool does something for you like a "clean deployment"? I don’t remember exactly, but I think the VisualStudio deployment loop was pretty simple:

• rebuild
• remove / remove old application from the device - it may delete an isolated resource
• install a new application on the device

So maybe the reason? Hm .. after a belated thought and re-reading your question again, you said you started the application from the applet, so this is probably not the case. Be sure to check the exceptions first in the first step!