Best place to store config info?

I write lots of little C# desktop utilities for myself and others. These are all full-blown apps with full UI's (menus, lots of controls, etc) .

Many of them allow the user to set various preferences and configurations (e.g., case sensitivity in searches, default email addresses, network parameters, file-naming preferences, etc, etc, depending on the app.)

Where is the best place to store config, options, or user-preference info that will be available each time the user starts the app? Sometimes I use the Registry, sometimes I use a separate config file (and I'm never sure what the "right" place is to put such a file) - and there are probably other options, too.

Different developers may have different opinions but what guidelines/questions should I use to decide?

Thanks in advance!

there is a default config system that is part of the standard runtime. typically it goes in the same place as the exe, and unless you do the loading of the app domain, is required / is defaulted to be there.

there's no need to reinvent the wheel. user defined settings can be designed visually in vs's resource editor. these settings are stored in isolated storage.

there's no wrong place to store setting info (aside from in the registry...), but make things easy on yourself and use what's provided.

Quote:

---

Originally Posted by MadHatter

there is a default config system that is part of the standard runtime. typically it goes in the same place as the exe, and unless you do the loading of the app domain, is required / is defaulted to be there.

there's no need to reinvent the wheel. user defined settings can be designed visually in vs's resource editor. these settings are stored in isolated storage.

there's no wrong place to store setting info (aside from in the registry...), but make things easy on yourself and use what's provided.

---

Most of the commercial applications I've looked at seem to use the Registry. (I have no idea what languages they're written in) For example, Microsoft IE stores the user's Home Page setting there, Nikon's scanners store various stuff, and the list of other apps that use the Registry is endless.

Visual Studio itself seems to store tons of things that I select under Tools | Options in the Registry (e.g., tab size). And if I change it in the Registry the change appears the next time I look in VS, so they're using the Registry as the primary storage for this information.

So when you say the Registry is the 'wrong' place for this, is the 'right' place (and methodology) documented somewhere? Is Microsoft doing a "do as we say, not as we do" thing here? Thanks in advance for further clarification.

I found where Microsoft documents a way to store user settings in .Net 2.0.

http://msdn.microsoft.com/en-us/libr...69(vs.80).aspx

It looks good and easy but since posting my response, above, I've gone back and looked at even more apps on my system, including several more Microsoft ones, including ones that were released just this year, and they all seem to use the Registry. So is there a catch to this new method or is it simply a legacy thing or what?

the reason .net included such a verbose config system is because the registry wasn't intended to be a database for application configuration settings.

Yes, lots of other apps use it. Does that make it appropriate justification? no.

.net was intended to be capable of using xcopy deployment. .ini and .config files exist to for configuration information. the registry exists to centralize configuration management for the operating system at large. the more non operating system things are added to it will degrade its overall performance. The longer your registry files get, the longer it takes to traverse them.

Some applications share configuration settings. When settings are shared across multiple applications, it would be appropriate to persist only those things to the registry (or at least the argument could be made). when you're persisting application specific information that are isolated to a single executable, or a set of executables in a common directory, its most appropriate to use the built in config system.