何时 - 以及为什么 - 应该在Windows注册表中存储数据？

作为开发人员,在注册表中存储配置/选项的工具是我生命中的祸根.我无法轻易跟踪这些选项的变化,无法轻松地将它们从机器移植到机器,这一切都让我真正渴望.INI文件的美好时光......

在编写我自己的应用程序时,我应该选择放入注册表而不是旧式配置文件,为什么？

1> James Curran..：

---

最初(WIN3)配置存储在windows目录中的WIN.INI文件中.

问题:WIN.INI变得太大了.

解决方案(Win31):与程序位于同一目录中的单个INI文件.

问题:该程序可能安装在网络上并由许多人共享.

解决方案(Win311):用户窗口目录中的单个INI文件.

问题:很多人可能共享一个Windows文件夹,无论如何它应该是只读的.

解决方案(Win95):注册表,每个用户都有单独的部分.

问题:注册表变得太大了.

解决方案(WinXP):大块的单个数据移动到用户自己的Application Data文件夹.

问题:适用于大量数据,但对于少量数据而言相当复杂.

解决方案(.NET):将少量固定的只读数据存储在与应用程序相同的文件夹中的.config(Xml)文件中,并使用API​​来读取它.(读/写或用户特定数据保留在注册表中)

---

Unix解决方案也远非理想:$ HOME使用点文件臃肿,你不知道他们大多数人做了什么.

---

Unix:配置存储在$ HOME/.your-app中,在一次迭代中解决.

---

@Leonel XDG实际上要求您将配置文件放入$ HOME / .config / your-app /中，该解决方案是为解决@grep对象问题而创建的。而且，令人惊讶的是，现代Linux（以及* BSD上的所有人都疯狂到足以使用GNOME）_also_在`gconf`套件中有一个注册表。FOSS会产生选择，这是肯定的;）

2> Jimoc..：

---

从用户的角度和程序员的角度来看,我不得不说除了文件关联或机器特定的设置之外,在注册表中放置一些东西确实不是很好.

我来自思想学院,他说程序应该可以从安装的任何地方运行,安装应该可以在机器内完全移动,甚至可以移动到另一台机器上,而不会影响它的运行.

任何可配置选项或必需的dll等(如果它们未共享)应驻留在安装目录的子目录中,以便轻松移动整个安装.

我使用了许多较小的实用程序,如果它不能安装在usb棒上并插入另一台机器并运行,那么它不适合我.

---

但安装通常在管理员控制下完成,而更新设置必须在用户控制下完成.想象一下,尝试更新设置 - 一个在用户身份下运行的应用程序,该应用程序只想写入仅限管理员访问的目录.这是注册表旨在解决的问题之一.

3> Toon Krijthe..：

---

微软政策:

在Windows 95之前,我们使用ini文件来获取应用程序数据.

在Windows 95 - XP时代,我们使用了注册表.

从Windows Vista,我们使用ini文件,虽然它们现在是基于xml的.

注册表取决于机器.我从来不喜欢它,因为它变慢了,找到你需要的东西几乎是不可能的.这就是我喜欢简单的ini或其他设置文件的原因.您知道它们的位置(应用程序文件夹或用户文件夹),因此它们易于携带且易读.

---

XML设置文件=难以解析的INI文件

---

@Fraser如果您认为解析XML很困难,那么您的业务就是错误的.

4> AndrewD..：

---

何时 - 由于遗留集成或者客户的系统管理员说"它应该如此",或者因为您使用较旧的语言进行开发而导致使用XML变得更加困难.

为什么 - 主要是因为注册表不像复制位于应用程序旁边的配置文件那样可移植(并且被称为几乎相同).

如果您正在使用.Net2 +,那么您已经获得了App.Config和User.Config文件,并且您无需在注册表中注册DLL,因此请远离它.

配置文件有自己的问题(见下文),但这些可以编码,你可以改变你的架构.

问题:应用程序需要可配置的设置.

解决方案:将设置存储在Windows文件夹中的文件(WIN.INI)中 - 使用节标题对数据进行分组(Win3.0).

问题:WIN.INI文件变得太大(并且变得凌乱).

解决方案:将INI文件中的设置存储在与应用程序相同的文件夹中(Win3.1).

问题:需要用户特定的设置.

解决方案:将用户设置存储在用户的窗口目录(Win3.11)中的用户特定INI文件或应用程序INI文件中的用户特定部分.

问题:安全性 - 某些应用程序设置需要是只读的.

解决方案:具有安全性以及特定于用户和计算机范围的部分(Win95)的注册表.

问题:注册表变得太大了.

解决方案:用户特定的注册表移动到用户自己的"Application Data"文件夹中的user.dat,并且仅在登录时加载(WinNT).

问题:在大型企业环境中,您登录多台计算机并且必须设置EACH ONE.

解决方案:区分本地(本地设置)和漫游(应用程序数据)配置文件(WinXP).

问题:xcopy无法像.Net的其余部分那样部署或移动应用程序.

解决方案:APP.CONFIG XML文件与应用程序位于同一文件夹中 - 易于阅读,易于操作,易于移动,可以跟踪是否更改(.Net1).

问题:仍然需要以类似(即xcopy部署)的方式存储用户特定的数据.

解决方案:用户本地或漫游文件夹中的USER.CONFIG XML文件和强类型(.Net2).

问题:CONFIG文件区分大小写(对人类不直观),需要非常特定的打开/关闭"标签",连接字符串无法在运行时设置,安装项目无法写入设置(就像注册表一样容易),无法轻易确定安装了每个新版本时,都会烧毁user.config文件和用户设置.

解决方案:使用ITEM成员在运行时设置连接字符串,在安装程序类中编写代码以在安装期间更改App.Config,如果未找到用户设置,则将应用程序设置用作默认值.

5> 小智..：

---

如果在Windows注册表中存储几个窗口位置和最近使用的项目列表,世界是否会结束？到目前为止,它对我来说还可以.

HKEY-CURRENT-USER是一个存储少量琐碎用户数据的好地方.这就是它的用途.仅仅因为其他人滥用它而似乎没有用于其预期目的.

---

......这对管理终端服务的设置很有帮助.