I am using a build in functionality of .NET to store the settings, which are conveniently called settings as well. This functionality automatically makes sure that the settings are stored on your computer and it does that per user on your system. So they end up somewhere in the application data for your user.
As long as that all works as expected that is fine of course. But when making updated versions things get a bit tricky. The settings functionality takes two things into account when determining where to store the data:
- Version of the application
- Folder name of the executable
The version of the application is something I don’t change often, only with major release. So the development release is version 1.3 for quite a while already. But the folder where the application is stored is something I don’t control of course. Some users prefer to keep different versions side by side, which I can understand, but that results in the user settings not being shared by the different versions. Most likely each new version will always start from scratch with all default settings. So if that annoys you, I would suggest that you always store the latest development release in a folder with the same name.
Having said all this, you know how the current implementation works. And hopefully it helps you to be less annoyed by loosing the settings when you upgrade. But I must also add I understand this is not a perfect situation. So I will be looking at better ways to store the user settings in the future. When I do that I will also look at related issues, like for example the desire to have different profiles for FS2004 and FSX models. But that is something for the future.