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

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.