views:

174

answers:

2

C# visual studio project: Properties.Settings.Default.SomeValueOrAnother has me baffled.

I have a relatively simple project. It saves a bunch of last-entered values between sessions, and restores them on next invocation. Was working fine. I changed a control so that the minimum allowed value was no longer 1, but was now 100. Last used value had been 3. On startup, it now complains that 3 is not a valid value.

Well, duh, of course – but hear the rest.

I have edited Settings in VS to default to 500. I have edited the exename.config file to contain 500 instead of 3. I have examined every possible config file (vshost.exe.config, the files in bin/debug, bin/release, obj/debug, obj/release. They all contain value=500. I have re-built repeatedly. I have copied just the exe and the config file to a separate PC, so that the development environment was not a factor. I still get this error message.

To further confuse me, on the dev PC, if I run (directly, not in the debugger) the exe in /obj/debug or /obj/release I do NOT get the error. If I run the ones under /bin I DO get the error. The config files have identical contents. If I copy the exe & config from /obj (the one that does not give an error on the dev PC) to another PC, I DO get the error.

I thought exename.config was all I had to deal with, but it looks like VS is doing something behind my back – at least something that I cannot find in the documentation. I imagine this is something trivial. If anyone can explain what I've missed I'd sure appreciate it. All I really want to do is reliably save some user settings from one run of the program to the next. And get this app to 'forget' that obsolete value.

TIA

Mickey

+1  A: 

Look for *.settings files in your solution. That's where the value that's used when you build your project will be stored .

Joel Coehoorn
Sorry, no. I checked this also and made sure it had the correct rather than obsolete values.Mickey
mickeyf
A: 

This was not the entire answer, but it did explain where the mystery values were being stored:

"This might help to some people dealing with Settings.settings and App.config: Watch out for GenerateDefaultValueInCode attribute in the Properties pane while editing any of the values in the Settings.settings grid in Visual Studio (VS2008 in my case). If you set GenerateDefaultValueInCode to True (True is the default here!), the default value is compiled into the exe (or dll), you can find it embeded in the file when you open it in a plain text editor. I was working on a console application and if I had defaults in the exe, the application always ignored the config file place in the same directory! Quite a nightmare and no information about this on the whole internet."

...in another post here. I am now individually testing values read from settings, rather than trusting it, and forcing them into valid range if required.

Truly an ugly, and well hidden, default. I haven't embedded data values in my executables since the days of CPM. Jeesh.

Thanks again, Microsoft.

mickeyf