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.