Infosys Microsoft Alliance and Solutions blog

« Writing my first WCF service on Vista | Main | Finding deserialization problems when using MSMQ with WCF »

User Settings Persistence in .Net 2.0

The other day a friend, having read my earlier blog on Settings in .net fwk 2.0 asked me a question about user settings. He had built an application where he was dealing with user settings and though he was getting the required behavior of user settings getting updated everytime he changed some value and using the new value on next load of the application also, but the mystery was he wasn't able to locate where the values were being saved?

I decided to look into this and created a small windows application which had a text box to input new values, a button to assign them and another button whose text would get updated based on the value in the text box. This value, I also storted as user settings by calling Setting.Default.Save(). I ran the application, set a new text and hit the update button and closed the application. When I ran the application again, I did see the button displaying the new value i had assigned in my previous run.

So far so good. I then opened the application configuration file and to my surprise found the initial default entry in the config file for the user setting. However little thought and this made perfect sense. If the user settings were to be stored in the application configuration file, it would require
1. Updating the configuration file to introduce user specific information like use ID to identify different  user sections
2. The previous point would then also require different reading logic for user settings, since then it would have to account for the user ID
3. With multiple users accessing the application and each saving their personalized values in the file, its size would grow and would then cause performance issues due to a larger file to load and parse.

On a side note, when working with VS, you will also notice a few additional files with .vshost extension. These file aren't necessary for actual execution of the application and more for VS's own use. Check out detailed information here.

So if it wasn't application configuration file, where would the values would. The logical explanation was the Documents and Settings directory that is usually used for storing user specific information. But where in this? I know Visual Studio (VS) itself uses directories like C:\Documents and Settings\atulg\Local Settings\Application Data\Microsoft\VisualStudio\8.0 and C:\Documents and Settings\atulg\Application Data\Microsoft\VisualStudio\8.0 to store information, so this is place I looked initially.

However this didn't show up anything convincing. I did get some pointers to isolated storage, but when I searched that directory, I didn't find anything remotely related to the application I was working with. As I continued to search, I decided to search using the application name in the Documents and Settings directory.

Sometimes these simpler methods return results much faster. I immediately found a directory with the name of my application (MyApp) at - C:\Documents and Settings\atulg\Local Settings\Application Data\MyApp. Note that Local Settings and Application Data are usually hidden directories and trying to browse for them in explorer will not show anything unless these are unhidden. For those of you, who are working with Vista, the directory would be C:\Users\atulg\AppData\Local\MyApp.

Opening the above directory, I found additional sub-directory within it and its name was a bit wierd. It was named as <application exe name>_Url_<some crazy combination of alphabets and numbers>. Maybe the crazy combination is base 64 encoding of some information, but that topic is for another day. This directory itself contained another sub directory as the version number of the application. In my case, it was So the entire structure (inside of C:\Documents and Settings\atulg\Local Settings\Application Data\) looked like


The final directory with version number seemed interesting and this meant that information stored within would be version safe. The surprising part is when I tried by updating the version number and re-running the application, it created another directory below MyApp itself. So the directory now looked like


If the newer version was housed within a different subdirectory alltogether, then what purpose the version numbered sub-directory served? I don't have an answer to this right now. However another point I noticed is that when you debug the application via VS, it creates a different directory structure as


In this case, the version numbered directories made sense since they are both within the same parent directory.

Getting back to our earlier quest, there exists a file within the version numbered directory called as user.config and needless to say, it is in this file that the information i was seeking existed.

The mystery over the location of persistence of user settings is hence solved. I checked that when modifying the version number of the application, and making a copy of my executable of earlier version, I could see the different values getting stored in appropriate directories. Running a particular version would load the values saved only for that version.

To wrap up, in case you don't want to use the latest stored values and want to revert to the default values, you can call Settings.Default.Reset(). This clears the user setting values from the user.config file also and hence the default values are loaded the next time the application starts up (unless ofcourse you saved a new set of values).


Cool explanation.
Here it solves the mystery of UserSettings storage :)
Thanks a ton!!

Thanks for the explanation.
This gives me a problem however. I want to be able to distribute new versions of my Application without wiping out user settings they previously saved. Any idea How can I do this?

@Chris: I was stuck with a few other things and hence the delay in response. I will check and on this and get back as I don't have an answer right away.

Well, there is some additional mystery to this.

If the AssemblyCompany attribute is set in the AssemblyInfo file, then the user.config is created in C:\Document and Settings\%userName%\Local Settings\Application Data\%AssemblyCompanyAttributeValue%\%AppName.vshost.exe_URL_nnnnnn...%\%version number% folder.
If AssemblyCompany attribute isn't set, then the %AppName.vshost.exe_URL_nnnnnn...% is found in Application Data folder itself.

So if I set the AssemblyCompany attribute value to Infosys in AssemblyInfo.cs file, the parent folder for user.config is created in
C:\Document and Settings\neeraj_kulkarni\Local Settings\Application Data\Infosys directory.

Isn't this fun? Microsoft seems to have followed a consistent pattern here.

Atul: Great article.


@Chris, it turns out that there is very easy way to ensure that your earlier version settings are preserved. There is a Settings.Default.Upgrade method that you can call which will pull all settings values from the previous version and set them for the new version. Obviously this works with only one previous version.

You can properly keep another User Setting like a boolean property called say "Loaded". In the Form Load event, check if this value is false. If False, do and upgrade and then set this to true. The code will be something like this

if (!Settings.Default.Loaded)
Settings.Default.Loaded = true;

Putting the Loaded property as User setting is important to ensure that each Users values are independantly upgrade.

If you don't want to upgrade all property values, you can always use the Settings.Default.GetPreviousVersion() method to load specific values of interest and apply them for the newer version.

@Neeraj, thanks for pointing out. I hadn't checked this earlier.

Thanks a lot.

Was looking for this for some time now.

Thanks for showing the location of the file.

Thanks for finding this out Atul. I ended up using something else in the end but this is good to know for future projects.

@Chris, I would like to know what method worked for you as well, is you can share?

Hi Guys,
I have got a strange problem with user.config. The error is coming can not update user config file and the path of the file. this error is coming from only one machine, he is running xp sp2. he is running under admin account. anybody got any clue. i use my software is a package.

Since the user config file sits in the user's documents and settings folder, the user may have edited the permissions on that folder and hence the file isn't accessible. Can you validate that?

Also if you can post the exact error message with any error #, that will help to find out more about the issue.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter