Where to persist application data between versions?

CB 46 Reputation points
2021-08-09T13:17:56.977+00:00

I have a wpf/.net desktop app here that allows the user to change and customize a very large file of settings. Right now I store this in a serialized file in IsolatedStorage. Which is the only method I've been able to work out on how to do this.

The problem is that if I send the user a new app revision, they uninstall and reinstall the new package. The directory Windows created for IsolatedStorage changes because the assembly is different (or something), thus even though the old settings are still there in AppData/Local/IsoaltedStorage/ blah blah, the application cant load them.

I am using this command to load and save the file. Q: How should this be done differently so that each version installed loads and saves to the same storage directory?

        IsolatedStorageFile storage = IsolatedStorageFile.GetStore(IsolatedStorageScope.User | IsolatedStorageScope.Assembly, null, null);
C#
C#
An object-oriented and type-safe programming language that has its roots in the C family of languages and includes support for component-oriented programming.
10,648 questions
XAML
XAML
A language based on Extensible Markup Language (XML) that enables developers to specify a hierarchy of objects with a set of properties and logic.
790 questions
{count} votes

1 answer

Sort by: Most helpful
  1. Michael Taylor 51,346 Reputation points
    2021-08-09T14:49:39.717+00:00

    MSDN has a good writeup (ignoring the context of the types involved as they aren't applicable here) on the available places to store user data depending upon a variety of factors. You mention WPF and isolated storage so I wonder if you're using a ClickOnce app or UWP. For ClickOnce there is a writeup on isolated storage and versioning here.

    In general users shouldn't be uninstalling old versions of your app first. That is wasteful. Your installer should detect older versions and automatically update them. This is pretty critical for not losing the previous settings and is simpler for the user. But that is a feature of your installer and beyond the current scope. If you're using ClickOnce and isolated storage then the installer will automatically copy the old settings files to the new folder. This is the recommended approach.

    If you need to store files across reinstalls then isolated storage won't work anymore. You'll need to use a traditional option.

    If the files are per-user then store the data in the user's Documents directory under a subfolder for your app. If you need per-version documents then use a versioning scheme you create otherwise just store them locally. This is the best option if the user may want to copy the files to another machine and continue using them or if the user needs to ensure the files are backed up. However they are visible to the user and can be deleted if desired so your app has to be ready for that.

    If you need to store per-user data that is configuration information and the user shouldn't be mucking with the files nor should they be easily copyable then store the files in the user's AppData directory (local or roaming depending upon your needs) under a subfolder for your app. This is where app settings are generally stored.

    If you need to store settings for all user's on a machine then use the public AppData directory (and subfolder) instead. All users will then have access. All these folders are accessible by using the Environment.GetFolderPath method. Do not hard code any of the paths as they vary by OS.

    For versioning you need to handle this yourself. For simple things like app settings I would recommend you put a version header in the file. When your app reads the file it looks at the version header to determine what settings are available. When you write the file out you should always write out the latest version. Note that version is based upon the version of the settings and not necessarily the version of the app. For example if you release 3 versions of your app but never add any new settings to store then the settings file can still be v1. Going this route allows your app to magically "import" older settings into new versions of the app.