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

Question

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

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

Answer 1

• 最初（WIN3）配置存储在windows目录的WIN.INI文件中。
• 问题：WIN.INI变得太大了。
• 解决方案（Win31）：与程序位于同一目录中的各个INI文件。
• 问题：该程序可能安装在网络上并由许多人共享。
• 解决方案（Win311）：用户窗口目录中的单个INI文件。
• 问题：很多人可能会共享一个Windows文件夹，无论如何都应该是只读的。
• 解决方案（Win95）：注册表，每个用户都有单独的部分。
• 问题：注册表变得太大了。
• 解决方案（WinXP）：将大块单个数据移动到用户自己的Application Data文件夹。
• 问题：适用于大量数据，但对于少量数据则相当复杂。
• 解决方案（.NET）：将少量固定的只读数据存储在与应用程序相同的文件夹中的.config（Xml）文件中，并使用API​​进行读取。 （读/写或用户特定数据保留在注册表中）

Answer 2

从用户角度和程序员角度来看，我不得不说除了文件关联或机器特定设置之外，在注册表中放置一些东西确实没有什么好处。

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

任何可配置选项或必需的dll等，如果它们不共享，则应位于安装目录的子目录中，以便轻松移动整个安装。

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

Answer 3

Microsoft政策：

• 在Windows 95之前，我们将ini文件用于应用程序数据。
• 在Windows 95 - XP时代，我们使用了注册表。
• 从Windows Vista，我们使用ini文件，尽管它们现在是基于xml的。

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

Answer 4

何时 - 由于遗留集成或您客户的系统管理员说“它应该如此”，或者因为您使用较旧的语言进行开发而导致使用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，并在未找到用户设置时将应用程序设置用作默认值。

Answer 5

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

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

Answer 6

您希望在用户的漫游配置文件中可用的设置可能应该放在注册表中，除非您真的想要手动查找用户的Application Data文件夹。 ： - ）

Answer 7

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

Answer 8

如果你正在开发一个新的应用程序并且你关心可移植性，你应该从不在windows注册表中存储数据，因为其他操作系统没有（windows）注册表（注意 - 这可能是显而易见的但经常被忽视）。

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

Answer 9

稍微偏离主题，但由于我看到人们担心可移植性，我用过的最好的方法是Qt的QSettings类。它抽象了设置的存储（Windows上的注册表，Mac OS上的XML首选项文件和Unix上的Ini文件）。作为班级的客户，我不必花费大脑周期来思考注册表或其他任何东西，它只是工作（tm）。

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

Answer 10

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

如果我查看我的文档和设置文件夹，我会看到许多使用Unix点符号设置文件夹的软件： .p4qt .sqlworkbench .squirrel-SQL .SunDownloadManager .xngr .antexplorer 。助理 .CodeBlocks .dbvis .gimp-2.4 .jdictionary .jindent .jogl_ext（等）

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

Answer 11

我个人使用注册表来存储安装路径以供（un）安装脚本使用。我不确定这是否是唯一可能的选择，但似乎是一个明智的解决方案。这是一个仅在Windows上使用的应用程序。

Answer 12

在.NET中确实没有必要。

以下是两个展示如何使用Project proerties来实现此目的的示例。

这些示例通过Windows用户项目属性执行此操作，但同样可以/可以由Application完成。

更多信息：

http://code.msdn.microsoft.com/TheNotifyIconExample

http://code.msdn.microsoft.com/SEHE

Answer 13

（讨论后期但是）简答：组策略。

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

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

Answer 14

我认为Windows注册表是一个好主意，但是由于应用程序开发人员的大量滥用以及微软不鼓励/强制执行的标准策略变成了难以管理的野兽。我讨厌使用它是出于你提到的原因，但是有些时候使用它是有道理的：

• 卸载应用程序后留下应用程序的痕迹（例如，如果再次安装应用程序，请记住用户的偏好）
• 在不同应用程序之间共享配置设置 - 组件