I'd cast my vote for XML format. The registry is deprecated as a location
for user preferences these days, for a variety of reasons. The .Net
framework supplies no managed classes for ini file access, so you have to
downshift to the Windows API; furthermore, ini files have only a single
level of hierarchy, whereas user preferences generally benefit from a deeper
hierarchical organization.
For location, consider investigating isolated storage (namespace
System.IO.IsolatedStorage). Depending on the options you use with it, it can
be isolated to individual users, and provides a semi-hidden location in the
file system which is, in essence, an encapsulated file system in its own
right. In it you can store anything that can be put in a file system (think
XML configuration file). If you're worried about your users going into their
preferences files with notepad and screwing them up (easy to do with XML),
isolated storage hides them from everyone except the most sophisticated
users. If you don't want to go to that much trouble, you can also simply use
Application.UserAppDataPath or Application.LocalUserAppDataPath as the
directory in which you site the XML configuration file. Don't use the
executable's directory, since you can't guarantee that a system
administrator on the customer's site won't lock down the directory for
security reasons. XmlDocument (namespace System.Xml) is probably the best
choice for loading, updating, and saving the preferences.
As you've noted, Microsoft considers the application configuration file to
be reserved for read-only application-wide settings (modified with notepad
only when required for tracing, debugging, etc.), and consequently it's a
poor place to put user preferences. It's also subject to the problem that
the directory might be locked down for security reasons. Even with that
said, I've seen at least one Microsoft-supplied sample in which the sample
writer supplied update capabilities for that file, presumably on the
assumption that it will be run only on a developer's machine that has only a
single user account, and possibly because the sample writer didn't want to
take the time to write the code for separate user preferences files.
If you go to
www.gotdotnet.com, you can probably find at least a dozen user
contributions that manage updatable application configuration files,
individual XML user preference files, registry access for user preferences,
and even ini files. Quality varies. The code that you have to write around
XmlDocument is kind of intricate in a few places, mostly around adding
attributes to elements and adding nodes when the parent node path doesn't
yet exist, so it might be worth taking a look at someone else's solution of
the problem even if you prefer to write your own. Like a lot of other
people, I suppose, I've written my own code for XML configuration files, but
when I looked around at gotdotnet with the idea of contributing it I decided
that the world didn't need yet another one, no matter how excellent
HTH,
Tom Dacon
Dacon Software Consulting
