Take the 2-minute tour ×

I have a .NET 2.0 Windows Forms application. Where is the best place the store user settings (considering Windows guidelines)?

Some people pointed to Application.LocalUserAppDataPath. However, that creates a folder structure like:

C:\Documents and Settings\user_name\Local Settings\Application Data\company_name\product_name\product_version\

If I release version 1 of my application and store an XML file there, then release version 2, that would change to a different folder, right? I'd prefer to have a single folder, per user, to store settings, regardless of the application version.

share|improve this question
I think this article covers the solution. –  Jorge Córdoba Aug 25 '08 at 16:50
add comment

7 Answers

up vote 51 down vote accepted

I love using the built-in Application Settings. Then you have built in support for using the settings designer if you want at design-time, or at runtime to use:

// read setting
string setting1 = (string)Settings.Default["MySetting1"];
// save setting
Settings.Default["MySetting2"] = "My Setting Value";

It does store the settings in a similar folder structure as you describe (with the version in the path). However, with a simple call to:


The app will pull all previous versions settings in to save in.

share|improve this answer
Thanks for the Upgrade() tip. –  Don Kirkby Sep 19 '08 at 20:20
the only annoying thing about Settings.Default is that you need to create them manually beforehand, unlike NSUserDefaults in Cocoa that returns nil if a setting does not exist. –  Ali Feb 3 '13 at 13:08
Which namespace is this in? I don't seem to have access to a Settings object in my .NET 4 winforms app. –  NickG May 22 '13 at 15:56
Properties.Settings.Default –  Trent Seed Jul 5 '13 at 2:06
Ryan Farley. How to use the above settings in multi user environment –  Anjali Apr 17 at 7:43
show 2 more comments

.NET applications have a built-in settings mechanism that is easy to use. The problem with it, in my opinion, is that it stores those settings off into a rather obscure directory and end users will not be able to find it. Moreover, just switching from debug to release build changes the location of this directory, meaning that any settings saved in one configuration are lost in the other.

For these and other reasons, I came up with my own settings code for Windows Forms. It's not quite as slick as the one that comes with .NET, but it's more flexible, and I use it all the time.

share|improve this answer
add comment

One approach that has worked for me in the past has been to create a settings class and use XML serialization to write it to the file system. You could extend this concept by creating a collection of settings objects and serializing it. You would have all of your settings for all users in one place without having to worry about managing the file system.

Before anyone gives me any flak for partially re-inventing the wheel, let me say a few things. For one, it is only a few lines of code to serialize and write the file. Secondly, if you have an object that contains your settings, you don't have to make multiple calls to the appSettings object when you load your app. And lastly, it is very easy to add items that represent your applications state, thereby allowing you to resume a long-running task when the application loads next.

share|improve this answer
If you're willing to build custom XML serialization, why not serialize it into a single application setting? That way you get to use the app settings infrastructure. Create a serializable class or type converter and then import the class using the app settings dialog. –  Don Kirkby Sep 19 '08 at 20:28
add comment

Or write your settings in a xml file and save it using Isolated Storage. Depending on the store you use it saves it in the Application Data folder. You can also choose a roaming enabled store which means when the user logs on a different computer the settings move with them.

share|improve this answer
add comment

Settings are standard key-value pairs (string-string). I could wrap them in an XML file, if that helps.

I'd rather use the file system instead of the registry. It seems to be easier to maintain. In support scenarios, if the user needs to manually open/change the settings, that would be easier if it's in the file system.

share|improve this answer
add comment

Isolated storage is primarily used for applications distributed using ClickOnce and are run in a secure sandbox. The base path is decided for you and you won't be able infer it in your code. The path will be something like "\LocalSettings\ApplicationData\IsolatedStorage\ejwnwe.302\kfiwemqi.owx\url.asdaiojwejoieajae....", not all that friendly. Your storage space is also limited.

Ryan Farley has it right.

share|improve this answer
add comment

I'd go down the folder list you posted except for the product version. You don't want the settings reset after an update is released.

I'm actually moving away from the registry for user settings because of the debug/footprint factor. I'm currently only storing a few basic settings (window size, position, version of a data file) in the registry, and I've run into more problems if an update goes bad or a user loses a second monitor and that is where the application was opening to. A few of them are savvy enough to understand regedit, but for the rest they have to do a reinstall, which is quick, but I think they grumble a bit. With the file based version, all I'd have to do is have them open up an XML file in Notepad and make a quick tweak.

In addition, I'm looking to make my application runnable off a USB flash drive, and having the settings tied into the file seems much friendlier to that process. I'm sure I can do some code to check/clean the registry, but I think most of us are already tired of the registry clutter that seems to eat up our machines nowadays.

I know there are some security tradeoffs to this, but none of the data I'm sorting is that critical to that cause, and I'm not suffering any performance hits due to the size of the application.

share|improve this answer
add comment

Your Answer


