6

I've been using the usual My.Settings... method when it came to saving settings for my program but I was just wondering, If I wanted to save program settings into the Registry and load those settings, are there any benefits when comparing with saving settings to a custom written file and loading those settings from the file.

Which would you prefer and why?

Zer0
  • 185
  • 1
  • 5
  • [Sharing your research helps everyone](http://meta.programmers.stackexchange.com/questions/6559/why-is-research-important). Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see [ask] – gnat Jul 09 '15 at 10:51
  • recommended reading: **[What is the problem with “Pros and Cons”?](http://meta.programmers.stackexchange.com/q/6758/31260)** – gnat Jul 09 '15 at 10:51
  • Although you are using .NET, wxWidgets [has a good writeup of how to use file- and registry-based configs](http://docs.wxwidgets.org/trunk/classwx_config_base.html) that is still applicable at a conceptual level. Essentially, you can abstract the storage of your settings to a point where _it does not matter_ where you store them from your application's point of view. –  Jul 09 '15 at 12:47

3 Answers3

7

A good starting point is Jeff Atwood's article: Was The Windows Registry a Good Idea?

It gives a lot of good reasons not to use the registry. Among them:

  • The registry is a single point of failure. That's why every single registry editing tip you'll ever find starts with a big fat screaming disclaimer about how you can break your computer with regedit.
  • The registry is opaque and binary. As much as I dislike the angle bracket tax, at least XML config files are reasonably human-readable, and they allow as many comments as you see fit.
  • The registry has to be in sync with the filesystem. Delete an application without "uninstalling" it and you're left with stale registry cruft. Or if an app has a poorly written uninstaller. The filesystem is no longer the statement of record-- it has to be kept in sync with the registry somehow. It's a total violation of the DRY principle.
  • The registry is monolithic. Let's say you wanted to move an application to a different path on your machine, or even to a different machine altogether. Good luck extracting the relevant settings for that one particular application from the giant registry tarball. A given application typically has dozens of settings strewn all over the registry.

Probably the only applications that may require the registry are:

  • COM applications. Without a central repository it'd be much harder to get the class ID (CLSID)
  • large scale applications that need to administer the configuration network-wide (storing the data in the registry gives you the possibility to use Admin Templates in a Group Policy).
manlio
  • 4,166
  • 3
  • 23
  • 35
3

I would suggest that the Windows Registry is best left to Windows itself to play with.

  • Parts of it are inaccessible to regular users.
  • Parts of it are inaccessible to certain types of application (32-bit processes running on 64-bit versions of Windows).
  • It's a completely proprietary storage mechanism, which can change, without warning, with any upgrade or security patch.
  • It's not easy to backup or restore parts of the Registry; it's really all or nothing.
  • Values held therein aren't portable; they're fixed onto one particular machine.

Contrast that with a simple, text file held in the user's Roaming profile directory:

They are accessible to the user (with no security or U.A.C. complications), the format and content of that file are completely under your control, they get captured by a regular, file system backup, they can get carried, seamlessly, onto every machine that the user logs onto and they're less likely to get lost if you have to reinstall your operating system.

Phill W.
  • 11,891
  • 4
  • 21
  • 36
  • 3
    One should add though, that the Registry is [**not intended to hold large amounts of data**](https://msdn.microsoft.com/en-us/library/windows/desktop/ms724881(v=vs.85).aspx). Such data should be saved into a file in the user's profile folders. If the location is not obvious or may vary, add a registry entry holding the file name. – JensG Jul 09 '15 at 12:19
  • 3
    Although I agree with your overall argument that user settings shouldn't be saved to the registry, you make some incorrect arguments. Although it is a completely proprietary storage mechanism, value retrieval is defined by an API that can't just "change, without warning, with any upgrade or security patch". That would be a breaking change, and Microsoft would publish about that--probably as change notes to a major version of Windows. Also, you can backup and restore parts of the Registry; it's just called Export and Import. – mgw854 Jul 09 '15 at 12:23
  • 1
    "with no security complications" is not necessarily a good feature... your other points are generally wrong. Right click on a key and select "export", you get that section of the tree exported as a plain text file. Registry values can and do roam - Windows cam roams the entire registry, and its API will never change. – gbjbaanb Jul 09 '15 at 13:29
  • "Right-click on a key": That assumes that you can *open* RegEdit, which a large fraction of users these days simply cannot do. "Registry values can roam": OK, Hadn't realised that. "Its API will never change": How, then, do you explain the whole Windows-on-Windows64 "sandboxing" idea, which prevents "little" processes from accessing swathes of the 64-bit Registry (because the data types therein "might" change in future). OK, not strictly an API change, but Our Friends in Redmond *have* changed the rules on us and will, no doubt, continue to do so. – Phill W. Jul 10 '15 at 11:03
1

In the distant past, I would have suggested using the registry (as opposed to an INI file). These days, I would lean toward file-based storage of settings and configuration. The user-changeable parts of the settings should be persisted using the Isolated Storage API.

OldFart
  • 199
  • 3