Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

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.

like image 834
Brad Avatar asked Sep 06 '11 18:09

Brad


4 Answers

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.

like image 122
Hans Passant Avatar answered Oct 31 '22 02:10

Hans Passant


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.

like image 3
Albin Sunnanbo Avatar answered Oct 31 '22 03:10

Albin Sunnanbo


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

like image 3
christiandersen Avatar answered Oct 31 '22 01:10

christiandersen


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.

like image 1
havardhu Avatar answered Oct 31 '22 01:10

havardhu