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

小开

您希望在用户的漫游配置文件中提供的设置可能应该放在注册表中，除非您实际上希望手动查找用户的 Application Data 文件夹。:-)

小开

微软政策:

在 Windows95之前，我们对应用程序数据使用 ini 文件。
在 Windows95-XP 时代，我们使用注册表。
在 WindowsVista 中，我们使用 ini 文件，尽管它们现在是基于 xml 的。

注册表依赖于计算机。我从来不喜欢它，因为它变得越来越慢，它几乎不可能找到你需要的东西。这就是为什么我喜欢简单的 ini 或其他设置文件。您知道它们在哪里(应用程序文件夹或用户文件夹) ，因此它们便于携带，并且人类可读。

小开

通常，如果你不在注册表中放置设置，你主要用它来获取当前的 Windows 设置，更改文件关联等。
现在，如果您需要检测您的软件是否已经安装，您可以在注册表中创建一个最小条目，这是您可以在任何配置中找到的位置。或在应用程序数据中搜索给定名称的文件夹。

如果我看我的文档和设置文件夹，我看到很多软件使用 Unix 点符号来设置文件夹: 。 p4qt 。 sqlworkbench 。松鼠-sql 。 SunDownloadManager 。 xngr 。一个探险家。助理。代码块。 dbvis 。 gimp-2.4 。 jdictionary 。 jindent . jogl _ ext (等等)

以及在应用程序数据中，包含编辑器名称或软件名称的各种文件夹。看起来这是目前的趋势，至少在便携式应用程序中是这样..。
WinMerge 使用稍微不同的方法，在注册表中存储数据，但在配置对话框中提供导入和导出选项。

小开

如果你正在开发一个新的应用程序，你关心可移植性，你应该 从来没有存储数据在 Windows 注册表，因为其他操作系统没有一个(窗口)注册表(注意-这可能是显而易见的，但往往被忽视)。

如果你只是为 Win 平台开发... 尽量避免它。配置文件(可能是加密的)是更好的解决方案。将数据存储到注册表中没有任何好处-(例如，如果您正在使用。NET).

小开

从用户的角度和程序员的角度来看，我不得不说，除非是文件关联或机器特定的设置，否则真的没有什么好的理由把东西放到注册表中。

我来自一个思想流派，这个流派认为程序应该可以在安装的任何地方运行，安装应该在一台机器内完全可移动，甚至可以移动到另一台机器上，而不会影响它的运行。

任何可配置的选项，或者所需的 dlls 等，如果它们不是共享的，应该驻留在安装目录的一个子目录中，这样就可以轻松地移动整个安装。

我使用很多小工具，如程序，所以如果它不能安装在一个 U 盘，插入另一台机器，只是运行，那么它不适合我。

小开

最佳答案

最初(WIN3)配置存储在 windows 目录中的 WIN.INI 文件中。
问题: WIN.INI 变得太大了。
解决方案(Win31) : 与程序位于同一目录的单个 INI 文件。
问题: 该程序可能安装在网络上，并由许多人共享。
解决方案(Win311) : 用户的 Window 目录中的单个 INI 文件。
问题: 许多人可能共享一个 Windows 文件夹，而且它应该是只读的。
解决方案(Win95) : 为每个用户分别设置注册表部分。
问题: 注册表变得太大了。
解决方案(WinXP) : 大块的单独数据移动到用户自己的应用程序数据文件夹。
问题: 适用于大量数据，但对于小量数据则相当复杂。
解决方案(。NET) : 存储在。Config (XML)文件放在与应用程序相同的文件夹中，并使用 API 读取它。(读/写或用户特定数据保留在注册表中)

小开

注册表读写是线程安全的，但文件不是。所以这取决于程序是否是单线程的。

小开

有点跑题，但是因为我看到人们关心可移植性，所以我使用过的最好的方法是 Qt 的 QSettings 类。它抽象设置的存储(Windows 上的注册表、 Mac OS 上的 XML 首选项文件和 Unix 上的 Ini 文件)。作为这个班级的一个客户，我不需要花费一个大脑周期去思考注册表或者其他什么东西，它只是工作(tm)。

Http://doc.trolltech.com/4.4/qsettings.html#details

小开

我相信 Windows Registry 是一个好主意，但是由于应用程序开发人员的滥用和微软不鼓励或强制执行的标准政策变成了一个难以管理的野兽。我讨厌使用它的原因你已经提到了，但是有些情况下使用它是有意义的:

卸载应用程序后留下应用程序的跟踪(例如，记住用户的首选项，以防应用程序再次安装)
在不同应用程序之间共享配置设置-组件

小开

如果在 Windows 注册表中存储一些窗口位置和最近使用的项目列表，世界是否会毁灭？到目前为止还行。

HKEY-CURRENT-USER 是一个存储少量琐碎用户数据的好地方。这就是它的作用。仅仅因为其他人滥用了它，而不为其预期目的使用它似乎是愚蠢的。

小开

我个人使用注册表来存储安装路径，以供(非)安装脚本使用。我不确定这是否是唯一的选择，但似乎是一个明智的解决方案。这当然是针对一个只在 Windows 上使用的应用程序。

小开

当 -由于遗留集成，或者因为客户的系统管理员说“应该如此”，或者因为您正在使用一种较老的语言进行开发，这使得使用 XML 变得更加困难，您不得不这样做。

为什么 -主要是因为注册表的可移植性不如复制应用程序旁边的配置文件(调用方式几乎相同)。

如果你吸毒的话。Net2 + 你有应用程序。配置和用户。配置文件，您不需要在注册表中注册 DLL 的，所以远离它。

配置文件有它们自己的问题(见下文) ，但是可以围绕这些问题进行编码，您可以更改您的体系结构。

问题: 应用程序需要可配置设置。
解决方案: 将设置存储在 Windows 文件夹中的文件(WIN.INI)中——使用节标题对数据进行分组(Win3.0)。
问题: WIN.INI 文件变得太大(并且变得混乱)。
解决方案: 将设置存储在与应用程序相同的 INI 文件夹中(Win3.1)。
问题: 需要特定于用户的设置。
解决方案: 将用户设置存储在用户的 Window 目录(Win3.11)中的特定于用户的 INI 文件中，或者存储在应用程序 INI 文件中的特定于用户的部分中。
问题: 安全性-一些应用程序设置需要是只读的。
解决方案: 注册表具有安全性以及用户特定的和机器范围的部分(Win95)。
问题: 注册表变得太大了。
解决方案: 用户特定的注册表移动到用户自己的“ Application Data”文件夹中的 user.dat，并且只在登录(WinNT)时加载。
问题: 在大型企业环境中，您登录到多台计算机，并且必须设置每台计算机。
解决方案: 区分本地(本地设置)和漫游(应用程序数据)配置文件(WinXP)。
问题: 不能像.Net 的其余部分那样 xcopy 部署或移动应用程序。
解决方案: APP.CONFIG XML 文件与应用程序放在同一个文件夹中-易于阅读，易于操作，易于移动，如果更改可以跟踪(。网络1)。
问题: 仍然需要以类似的(即 xcopy 部署)方式存储用户特定的数据。
解决方案: 用户本地或漫游文件夹中的 USER.CONFIG XML 文件和强类型(. Net2)。
问题: CONFIG 文件区分大小写(对人类来说不是直观的) ，需要非常特定的打开/关闭“标签”，连接字符串不能在运行时设置，安装项目不能写设置(像注册表一样容易) ，不能轻易确定 user.CONFIG 文件和用户设置随着每个新版本的安装而发生变化。
解决方案: 使用 ITEM 成员在运行时设置连接字符串，在 Installer 类中编写代码以更改 App。配置，如果找不到用户设置，则使用应用程序设置作为默认设置。

小开

在.NET 中真的从来没有需要。

下面是两个示例，展示了如何使用 Project 属性来实现这一点。

这些示例通过 Windows 用户项目属性实现这一点，但应用程序也可以/可以实现同样的功能。

Http://code.msdn.microsoft.com/sehe

小开

简短的回答: 团队策略。

如果您的客户的 IT 部门想要强制执行与 Windows 或您正在编写或捆绑的组件相关的设置，例如链接速度、自定义错误消息或要连接的数据库服务器，这仍然通常通过组策略来完成，它的最终表现形式是存储在注册表中的设置。这些策略从 Windows 启动或用户登录时开始执行。

有一些工具可以创建自定义 ADMX 模板，这些模板可以将组件的设置映射到注册表位置，并为管理员提供一个公共接口来强制执行他需要强制执行的策略，同时只显示那些有意义的设置来强制执行这些策略。