tags:

views:

1510

answers:

9

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.

Thanks!

A: 

Wht kind of settings are you looking to store?

I'm probably showing my .NET ignorance but , is there a reason you can't just use the Registry?

Mark Biek
A: 

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.

LD2008
A: 

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 too. A few of them are saavy 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 key, 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 app.

Dillie-O
A: 

I think this article covers the solution.

Jorge Córdoba
+19  A: 

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:

Settings.Default.Upgrade();

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

Ryan Farley
Thanks for the Upgrade() tip.
Don Kirkby
+1  A: 

is there a reason you can't just use the Registry?

Using the registry would require that the user has write access to the registry. Can't assume that will always be the case.

Ryan Farley
A: 

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.

Jason Z
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
A: 

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.

Lars Truijens
A: 

Isolated storage is primarily used for apps distributed using click-once 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.

Damian Hickey