当编写自己的应用程序时,我应该选择将什么内容放入注册表而不是老式的配置文件中,为什么?
$HOME/.config/your-app/
中,这是为了解决 @grep 指出的问题而创建的一种解决方案。而且,令人惊讶的是,现代 Linux(以及任何使用 GNOME 的 *BSD 用户)也在 gconf
套件中拥有注册表。自由开源软件肯定会带来选择。 ;) - new123456从用户和程序员的角度来看,除了文件关联或机器特定设置之类的东西外,我认为没有好的理由将某些内容放入注册表中。
我来自这样一个思想的学派:程序应该可以在安装任何位置上运行,在机器内部完全可移动,甚至移到另一台机器上也不会影响其运行。
任何可配置选项或所需的DLL等,如果它们不是共享的,应该位于安装目录的子目录中,以便整个安装可以轻松移动。
我使用许多像是实用程序一样的小型程序,因此,如果不能在USB存储设备上安装并插入到另一台机器上并直接运行,则对我而言这不是一个好的选择。
何时使用 - 当你被迫与传统集成或因为客户的系统管理员说“必须如此”或者因为你正在开发一种较旧的语言而使得使用XML更加困难时。
为什么使用 - 主要是因为注册表不像将配置文件复制到应用程序旁边那样易于移植(并且几乎叫相同的名称)。
如果你使用的是.NET 2+,则拥有App.Config和User.Config文件,您不需要在注册表中注册DLL,因此请避免使用它。
配置文件也有其自身的问题(请参见下文),但是这些问题可以编码解决,并且您可以修改您的架构。
微软政策:
注册表是与机器相关的。我从来都不喜欢它,因为它越来越慢,几乎不可能找到你需要的东西。这就是为什么我喜欢简单的 ini 或其他设置文件。你知道它们在哪里(应用程序文件夹或用户文件夹),所以它们易于移植和阅读。
如果你在Windows注册表中存储了一些窗口位置和最近使用的项目清单,世界会毁灭吗?这对我来说一直都很好。
HKEY-CURRENT-USER是一个非常适合存储少量用户数据的好地方。这就是它的用途。因为其他人滥用了它,所以不使用它的本意似乎有点愚蠢。
注册表的读写是线程安全的,但文件不是。因此,这取决于您的程序是否单线程。
如果您希望在用户的漫游配置文件中使用的设置可用,那么最好将其放在注册表中,除非您真的想手动查找用户的应用程序数据文件夹。
个人而言,我曾使用注册表来存储安装路径,以供(卸载)脚本使用。我不确定这是否是唯一的可行选项,但似乎是一个明智的解决方案。当然,这是针对仅在 Windows 上使用的应用程序。