When - and why - should you store data in the Windows Registry?

As a developer, tools that store configuration/options in the registry are the bane of my life. I can't easily track changes to those options, can't easily port them from machine to machine, and it all makes me really yearn for the good old days of .INI files...

When writing my own applications, what - if anything - should I choose to put in the registry rather than in old-fashioned configuration files, and why?

• Originally (WIN3) configuration was stored in the WIN.INI file in the windows directory.
• Problem: WIN.INI grew too big.
• Solution (Win31): individual INI files in the same directory as the program.
• Problem: That program may be installed on a network and shared by many people.
• Solution(Win311): individual INI files in the user's Window directory.
• Problem: Many people may share a windows folder, and it should be read-only anyway.
• Solution (Win95): Registry with separate sections for each user.
• Problem: Registry grew too big.
• Solution (WinXP): Large blocks of individual data moved to user's own Application Data folder.
• Problem: Good for large amounts of data, but rather complex for small amounts.
• Solution (.NET): small amounts of fixed, read-only data stored in .config (Xml) files in same folder as application, with API to read it. (Read/write or user specific data stays in registry)

Coming at this both from a user perspective and a programmers perspective I would have to say there really isn't a good exceuse to put something in the registry unless it is something like file associations, or machine specific settings.

I come from the school of thought that says that a program should be runnable from wherever it is installed, that the installation should be completely movable within a machine, or even to another machine and not affect the running of it.

Any configurable options, or required dlls etc, if they are not shared should reside in a subdirectory of the installation directory, so that the whole installation is easily moved.

I use a lot of smaller utility like programs, so if it cant be installed on a usb stick and plugged into another machine and just run, then its not for me.

When - You are forced to due to legacy integration or because your customer's sysadmin says "it shall be so" or because you're developing in an older language that makes it more difficult to use XML.

Why - Primarily because the registry is not as portable as copying a config file that is sitting next to the application (and is called almost the same).

If you're using .Net2+ you've got App.Config and User.Config files and you don't need to register DLL's in the registry so stay away from it.

Config files have their own issues (see below), but these can be coded around and you can alter your architecture.

• Problem: Applications needed configurable settings.
• Solution: Store settings in a file (WIN.INI) in the Windows folder - use section headings to group data (Win3.0).
• Problem: WIN.INI file grew too big (and got messy).
• Solution: Store settings in INI files in the same folder as the application (Win3.1).
• Problem: Need user-specific settings.
• Solution: Store user-settings in user-specific INI files in the user's Window directory (Win3.11) or user-specific sections in the application INI file.
• Problem: Security - some application settings need to be read-only.
• Solution: Registry with security as well as user-specific and machine-wide sections (Win95).
• Problem: Registry grew too big.
• Solution: User-specific registry moved to user.dat in the user's own "Application Data" folder and only loaded at login (WinNT).
• Problem: In large corporate environments you log onto multiple machines and have to set EACH ONE up.
• Solution: Differentiate between local (Local Settings) and roaming (Application Data) profiles (WinXP).
• Problem: Cannot xcopy deploy or move applications like the rest of .Net.
• Solution: APP.CONFIG XML file in same folder as application - , easy to read, easy to manipluate, easy to move, can track if changed (.Net1).
• Problem: Still need to store user-specific data in a similar (i.e. xcopy deploy) manner.
• Solution: USER.CONFIG XML file in user's local or roaming folder and strongly-typed (.Net2).
• Problem: CONFIG files are case-sensitive (not intuitive to humans), require very specific open/close "tags", connection strings cannot be set at run-time, setup projects cannot write settings (as easily as registry), cannot easily determine user.config file and user settings are blown with each new revision installed.
• Solution: Use the ITEM member to set connection strings at runtime, write code in an Installer class to change the App.Config during install and use the application settings as defaults if a user setting is not found.

Microsoft policy:

• Before windows 95, we used ini files for application data.
• In the windows 95 - XP era, we used the registry.
• From windows Vista, we use ini files although they are now xml based.

The registry is machine dependent. I have never liked it because its getting to slow and it is almost imposible to find the thing you need. That's why I like simple ini or other setting files. You know where they are (application folder or a user folder) so they are easy portable, and human readable.

Is the world going to end if you store a few window positions and a list of most recently used items in the Windows registry? It's worked okay for me so far.

HKEY-CURRENT-USER is a great place to store trivial user data in small quantities. That's what it's for. It seems silly not to use for its intended purpose just because others have abused it.

Registry reads and writes are threadsafe but files are not. So it depends on whether or not your program is single threaded.

Settings that you want to have available in a user's roaming profile should probably go in the registry, unless you actually want to go to the effort of looking for the user's Application Data folder by hand. :-)

If you are developing a new app and you care about portability you should NEVER store data in windows registry since other OS don't have a (windows) registry (duh note - this may be obvious but gets often overlooked).

If you're only developing for Win platforms ... try to avoid it as much as possible. Config files (possibly encrypted) are a way better solution. There's no gain in storing data into the registry - (isolated storage is a much better solution for example if you're using .NET).

Slightly off-topic, but since I see people concerned about portability, the best approach I've ever used is Qt's QSettings class. It abstracts the storage of the settings (registry on Windows, XML preference file on Mac OS and Ini files on Unix). As a client of the class, I don't have to spend a brain cycle wondering about the registry or anything else, it Just Works (tm).

http://doc.trolltech.com/4.4/qsettings.html#details

Usually, if you don't put settings in registry, you use it mostly to get current Windows settings, change file associations, etc.
Now, if you need to detect if your software is already installed, you can make a minimal entry in registry, that's a location you can find back in any config. Or search a folder of given name in Application Data.

If I look at my Document and Settings folder, I see lot of softwares using the Unix dot notation for setting folders: .p4qt .sqlworkbench .squirrel-sql .SunDownloadManager .xngr .antexplorer .assistant .CodeBlocks .dbvis .gimp-2.4 .jdictionary .jindent .jogl_ext (etc.)

and in Application Data, various folders with editor names or software names. Looks like being the current trend, at least among portable applications...
WinMerge uses a slightly different approach, storing data in registry, but offering Import and Export of options in the config dialog.

I believe that Windows Registry was a good idea, but because of great abuse from application developers and standard policies not encouraged/mandated by Microsoft grew into an unmanageable beast. I hate using it for the reasons you've mentioned, there are however some occasions that it makes sense using it:

• Leaving a trace of your application after your application has been uninstalled (e.g. remember user's preferences in case the application is installed again)
• Share configuration settings between different applications - components

Personally I have used the registry to store install paths for use by the (un)install scripts. I'm not sure if this is the only possible option, but seemed like a sensible solution. This was for an app that was solely in use on Windows of course.

In .NET there really is NOT ever a need.

Here are 2 examples that show how to use Project proerties to do the this.

These examples do this by Windows User Project Properties, but the same could/can be done by Application as well.

More here:

http://code.msdn.microsoft.com/TheNotifyIconExample

http://code.msdn.microsoft.com/SEHE

(late to the discussion but) Short Answer: Group Policy.

If your customer's IT department wants to enforce settings related to Windows or the component(s) you're writing or bundling in, such as a link speed, or a custom error message, or a database server to connect to, this is still typically done via Group Policy, which makes its ultimate manifestation as settings stored in the registry. Such policies are enforced from the time Windows starts up or the user logs in.

There are tools to create custom ADMX templates that can map your components' settings to registry locations, and give the administrator a common interface to enforce policies (s)he needs to enforce while showing them only those settings that are meaningful to enforce this way.