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 18.104.22.168. 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).