Today I ran into this bug in the software I'm working on. I was building a log on mechanism, that would persist a users security token to Isolated Storage. I wanted to do this, because it would enable the application to automatically log on if a valid token was still available.
I actually had this whole thing working last week, but I changed some code on the server end of things and wanted to test my sliding expiration code. So I tested the above functionality only to find out my token was no longer persisted. After extensive debugging, including writing code to watch any changes on the folder holding the Isolated Storage, I came up with nothing.
Getting frustrated, I started searching the Silverlight.net forums for anything on Isolated Storage, to see if anyone had similar issues. I then ran into a post mentioning the Save method on the IsolatedStorageSettings class. I wasn't aware of this method and reading the post, I found out I wasn't the only one. It is not actually mentioned in the video on this topic either.
It is understandable as Save is called automatically whenever a Silverlight application ends, persisting the settings just in time and giving optimal performance, however...
...if, for some reason, an exception occurs while persisting the settings, this results in the settings not being persisted. And that's not the worst. You will NOT notice it, as you will not see the exception.
In my case, I was stupid enough to make one of the classes I use to store information internal, instead of public (as it was before), breaking the serialization of this class. I didn't get any exceptions, until I started calling IsolatedStorageSettings.Save() from code.
My conclusion from all this? Call the save method at some point in your application. It can save you a lot of headaches.
Please leave any comments, questions, remarks below. I'm allways happy to read them and reply.