I’ve recently discovered the IsolatedStorage facilities in .net, and I’m wondering when I should use them for my application data versus when I should use (e.g.) Application.LocalUserAppDataPath.
One thing that I’ve noticed is that Application doesn’t exist outside of a winforms app, so it seems that IsolatedStorage might make sense for a class library that needs some specific storage, especially if that library might be used by both a web app and a winforms app. Is that the only distinguishing point, or is there more to it?
(As a rule, up ’til now, I’ve made the app provide a file stream to the library when the library might need some sort of external storage— in general, I don’t like the idea of a library having some sort of state external to the caller’s context.)
IsolatedStorage has a couple interesting features that might make you opt for it:
Even very low trusted applications (such as click-once) can access isolated storage. Not all applications can have access to AppData. Depending on the security policy imposed on the application, IsolatedStorage can also be limited, but it usually is more accessible than AppData/file system.
IsolatedStorage storage requirements can be controlled by administrator policy.
You don’t have to know where or how isolated storage data is stored. It has a uniform API for accessing it on all systems you can completely ignore the underlying path that it is stored in. As you noted, this is very useful for a library which may have no idea how the hosting application stores data.
You can also have data stored data in isolated storage with vary levels of isolation very easily. See the IsolatedStorageScope values for more information. This is its namesake, so I guess I should have listed this point first 🙂
On the downside:
Some useful links: