tags:

views:

934

answers:

5

Hello all -

I thought I knew this, but today I'm being proven wrong - again.

Running VS2008, .NET 3.5 and C#. I added the User settings to the Properties Settings tab with default values, then read them in using this code:

myTextBox.Text = Properties.Settings.Default.MyStringProperty;

Then, after the user edits the value in the options dialog I save it like this:

Properties.Settings.Default.MyStringProperty = myTextBox.Text;
Properties.Settings.Default.Save();

My question is, where is this new value saved? the MyApp.exe.config file in the executable directory is not updated, it still contains the default values. Plus, as far as I can tell, none of the other files in that directory are updated either! However, when the program reads the value back in, it gets the changed value, so I know it's saved somewhere...

This isn't just academic, I needed to be able to manually edit the value this morning and got myself stumped when I couldn't find anything that was changing.

Thanks for any insight, Dave

A: 

User-specific settings are saved in the user's Application Data folder for that application. Look for a user.config file.

I don't know what you expected, since users often don't even have write access to the executable directory in the first place.

Joel Coehoorn
A: 

There is a folder called "Properties" under your project root folder, and there are *.settings file under that folder. That's where it gets stored.

J.W.
this is wrong. the default value is stored there not the users changed value..
Stan R.
it's right _during developement_. After deployment they go elsewhere.
Joel Coehoorn
i had this running in a development environment and the file remained unchanged. it only stores the default value there, not the updated.
Stan R.
Stan R is correct, it only stores the default value. Not the values you may change to during debugging.
Anonymous Type
+2  A: 

In order to work with newer versions of Windows' policy of only allowing read access by default to the Program Files folder (unless you prompt for elevation with UAC, but that's another topic...), your application will have a settings folder under %userprofile%\appdata\local or %userprofile%\Local Settings\Application Data depending on which version of Windows you're running, for settings that are user specific. If you store settings for all users, then they'll be in the corresponding folder under C:\users or C:\Documents and Settings for all user profiles (ex: C:\users\public\appdata\local).

jasonh
Also, the .config generated in Visual Studio, which ends up in the executable's folder, I believe is only used for debugging. When packaging up the final application, you don't include this .config, as it's generated the first time the user runs the application.
Will Eddins
Newer versions? This has been the case since windows 2000. You just got away with it because you were running as administrator.
Joel Coehoorn
That does it. It makes perfect sense now that it's explained to me - not sure why I didn't "get it" earlier, but...Anyway, yours was the first, most complete explanation, so you get the points.
DaveN59
@Joel Coehoorn: True, however now in the administrator account in Windows Vista and on, you cannot get write access to Program Files without a UAC elevation prompt by default. That's the policy that changed. :)
jasonh
A: 

it is saved in your Documents and Settings\%user%\Local Settings\Application Data......etc search for a file called user.config there

the location may change however.

Stan R.
Actually, the correct environment variable for user-specific properties is %userprofile%. Specifying Documents and Settings under Vista or 7 will result in either a missing folder or missing permissions to the folder it does find.
jasonh
A: 

This is such a pathetic nightmare that it makes me wish I'd never tried to use settings at all. I cannot get the correct value during debug after 45 mintues of trying because there is no way to figure out where blasted data is stored. Further, a .dll which provides UI cannot use data binding to a settings object provided by another assembly. This makes them worse than useless.

Do not use the settings object. Just serialize a hashmap and get on with your life.