Properties.Settings is not the value I expect it to be

Question

I have a setting in my project that, when referenced from code (i.e. i hover over the object I can see the value), is not the same as what is in the Properties.Settings file. It is an old value. I can go to the settings editor and update the value to something else but the old value persists. If I use .Properties.Settings.Default.Save() method the setting will be changed but that change is not reflected in the editor when I stop debugging. I can open up the Settings.settings file in a text editor and it will show me the same thing as what is in the settings editor in VS. I can also search my computer for other Settings.settings files and only that one shows up (others do show up but they are clearly unrelated, have old date modifieds and would not have the same setting name.)

Where is this file and why is the value different than what I think it should be?

Edit:

I could not get my original setting variable to be synced up again so I created a new setting variable with the setting GUI interface. And it seems to be propagating through properly. All of the files everyone was suggesting I look in had the values I wanted my setting variable to be but when I ran a debug session and looked at the same variable it was some old value that I could not trace.

Now that I think back, about 1.5 months ago I had experienced a similar problem with another variable but I didn't dig this deep that time. I had to do the same thing. Make a new similarly named variable, delete the old one and move one.

Edit 2:

Changing the setting variable name and letting VS propagate that change through the program on it's own seems to be a kind of hard reboot too.

Kosaka

The Settings work perfectly. You are doing something wrong. Impossible to say what for lack of details. – Emmalynn

I agree... Usually the program is right and I'm wrong. But where am I wrong. – Kosaka

Answer 1

You haven't found the settings file. It is not named Setting.settings, that's a project file. It is named "user.config" and stored in a directory with a strange name like:

C:\Users\HPassant\AppData\Local\MyCompany\
WindowsFormsApplication1._Url_ghbcotszbdzyqv2ovpc1keo1yctxkcw5\1.0.0.0

Where "HPassant" is the user name, "MyCompany" is the [AssemblyCompany] attribute, "WindowsFormsApplication1" is the project name, followed by a hash of various values, followed by the [AssemblyVersion]. You can see the algorithm with Reflector or ILSpy, look at the ClientConfigPaths class constructor.

Guilder

All these different file instances seems to be out of sync somehow. I HAD copied the project to a flash drive so I could work on it elsewhere and that's when this started but the error is in the original. My method of copying was to zip it. there was no drag and drop or anything that would displace an original file... – Kosaka

You are not going to copy the user.config file this way. Whatever machine you copied it to is going to start running the program without a user.config file. Getting settings out of sync between machines is pretty much guaranteed. Code accordingly. – Guilder

this lesson is learned the hard way. Is there a way to easily move a project to another computer to avoid this kind of thing in the future? (while I was experiencing this error on the copied file the original question is based on the original uncopied file) – Kosaka

It isn't that clear to me why this is a problem. Use user-scope settings only to store non-critical convenience values. Last size and position of the main window, that kind of stuff. It isn't otherwise a substitute for your own data files. – Guilder

I think I figured out what was happening. and after many headaches I found my user.config files were being saved here C:\Documents and Settings\[me]\Local Settings\Application Data\[company]\[app].vshost.exe_StrongName_ttoboiqesqszjcolu4xnyocamaaop1yg\1.0.0.0 instead of here: C:\Documents and Settings\[me]\Local Settings\Application Data\[company]\[app].exe_Url_c1ygid5lz3045ryrnckbiubtgfsqlwmy\1.0.0.0. When I'd click the Synchronize button in my settings.settings page it would not be able to find that user file. What an experience... – Kosaka

@Kosaka Thanks for the comment with solution.Still helpful after 9 years!! – Stall

@Kosaka Also Hi-Five: I work in environmental company as Developer and develop tools for clients to track their environmental compliance! Seen very less people with similar job desc as mine! – Stall

Answer 2

The default Properties.Settings value is overridden by the values in app.config.

In case of a deployed application app.config is renamed to YourApplicationName.exe.config and is the recommended way to handle configuration of application parameters.

Romilda

I see this file now. So I guess they have come out of sync. How can I get all these versions of my User settings to sync back up. I have not published the program yet btw. – Kosaka

Answer 3

I changed the Settings Scope from User to Application that solved my problem.

Coltun

Answer 4

When you save your settings, the settings are saved to the YourApplicationName.exe.config, as @Albin Sunnanbo explained.

So when you call Settings.Default.Save() you are changing this file, not app.config in your project. Your binaries have no knowledge of app.config, they only care about the deployed copy.

There are multiple scopes for a settings variable. If you set the scope to Application, you will only have one 'instance' of this value. If you set it to User, each unique windows user will have its own copy of the settings.

What you provide in app.config / Properties.Settings are default values. They will be overwritten in YourApplicationName.exe.config when you call Settings.Default.Save().

When debugging, you will find the YourApplicationName.exe.config in your /bin/debug folder. Look there, and you will see that the values in your application are the same as in this file, not the ones in app.config.

Grantland

\bin\Debug\YourApplicationName.exe.config, app.config, and settings.settings all say the same thing (and the thing I want them to say) but that's not what is output when the application runs. See my edit in original. – Kosaka