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

Question

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

Answer 1

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.

Answer 2

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

Answer 3

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

Answer 4

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.

Answer 5

(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.

Answer 6

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.