Hi,
When debugging my project in Visual Studio 2008, my Settings.settings file keeps getting reset between builds. Is there a way to prevent this from happening?
Thanks.
+1
A:
Off the top of my head I think you can set in the properties of the file (in Visual Studio right click, Properties) an option to "do not copy" when the project is built/run. What is happening probably is when your project is built, the settings file is copied to the debug bin directory, overwriting the settings file from the previous run.
AaronLS
2009-08-04 17:34:03
I just checked that option and it's already set to "do not copy".
Lenard
2009-08-04 19:00:01
+1
A:
I believe Settings.settings files are saved based on the current version number, basically as a "feature" where settings are not saved between differing versions of the same program on a machine. Assuming you're incrementing the version number automatically when compiling (1.0.* in AssemblyInfo.cs), you'll be resetting your settings everytime you compile a new version.
To correct this, the best course would be to serialize your own settings file to the Application Data directory.
Will Eddins
2009-08-04 18:17:25
Not sure how that would be considered a feature by Microsoft. Can you imagine all the complaints there would be every time Microsoft updated their software? Why would they think it would be any different for "us" developers? :) Thanks for your reply!
Lenard
2009-08-04 19:07:24
It's not an issue if you update your version numbers manually. The end result is that the user can install versions 1.0, 1.5, 1.7, and 2.0 of your software, and they will each have their own unique settings being saved. For settings being shared between these 4 applications, you should be saving your own settings file in a shared location.
Will Eddins
2009-08-04 19:13:35
I have never liked the behavior of any of the application settings features provided by MS. It's ashamed because there seems to be alot of framework there, but I find it easier to just cook up my own.
AaronLS
2009-08-05 23:10:24
+4
A:
Okay, I found out the answer I was really looking for. Basically, you need to call LocalFileSettingsProvider.Upgrade. However, since I will be deploying using ClickOnce, it will do it for you automatically.
Q: Okay, but how do I know when to call Upgrade?
A: Good question. In Clickonce, when you install a new version of your application, ApplicationSettingsBase will detect it and automatically upgrade settings for you at the point settings are loaded. In non-Clickonce cases, there is no automatic upgrade - you have to call Upgrade yourself. Here is one idea for determining when to call Upgrade:
Have a boolean setting called CallUpgrade and give it a default value of true. When your app starts up, you can do something like:
if (Properties.Settings.Value.CallUpgrade)
{
Properties.Settings.Value.Upgrade();
Properties.Settings.Value.CallUpgrade = false;
}
This will ensure that Upgrade() is called only the first time the application runs after a new version is deployed.
Lenard
2009-08-06 17:07:42
A:
Amongst other reasons, the Settings file keeps getting reset each time you Debug simply because the next time you Debug, you'll be able to test the whole application all over again. Not resetting the Settings may lead to undetected bugs.
baeltazor
2009-08-07 18:39:50