133

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

在编写我自己的应用程序时，我应该选择将什么（如果有的话）放入注册表而不是老式的配置文件，为什么？

4

14 回答 14

78
  • 最初（WIN3）的配置存储在windows目录下的WIN.INI文件中。
  • 问题：WIN.INI 变得太大。
  • 解决方案（Win31）：与程序在同一目录中的单个 INI 文件。
  • 问题：该程序可能安装在网络上并由许多人共享。
  • 解决方案(Win311)：用户Window目录下的个别INI文件。
  • 问题：很多人可能共享一个windows文件夹，无论如何它应该是只读的。
  • 解决方案 (Win95)：每个用户都有单独的部分的注册表。
  • 问题：注册表变得太大。
  • 解决方案 (WinXP)：将大块的单个数据移动到用户自己的应用程序数据文件夹中。
  • 问题：适用于大量数据，但对于少量数据则相当复杂。
  • 解决方案 (.NET)：将少量固定的只读数据存储在与应用程序相同的文件夹中的 .config (Xml) 文件中，并使用 API 来读取它。（读/写或用户特定数据保留在注册表中）
于 2008-11-06T12:33:30.013 回答
17

从用户的角度和程序员的角度来看，我不得不说将某些内容放入注册表中确实没有一个好的借口，除非它是文件关联或机器特定设置之类的东西。

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

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

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

于 2008-11-06T12:17:39.453 回答
14

什么时候- 由于遗留集成或者因为您的客户的系统管理员说“应该这样”或者因为您正在使用更旧的语言进行开发，这使得使用 XML 变得更加困难，您被迫这样做。

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

如果您使用的是 .Net2+，则您有 App.Config 和 User.Config 文件，并且您不需要在注册表中注册 DLL，因此请远离它。

配置文件有其自身的问题（见下文），但可以围绕这些问题进行编码，并且您可以更改您的架构。

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

微软政策：

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

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

于 2008-11-06T12:10:48.983 回答
9

如果您在 Windows 注册表中存储一些窗口位置和最近使用的项目列表，世界会结束吗？到目前为止，它对我来说还不错。

HKEY-CURRENT-USER 是存储少量用户数据的好地方。这就是它的用途。仅仅因为其他人滥用了它而不将其用于预期目的似乎很愚蠢。

于 2008-11-06T13:28:20.277 回答
6

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

于 2008-11-06T12:48:22.760 回答
4

您希望在用户的漫游配置文件中可用的设置可能应该放在注册表中，除非您真的想要手动查找用户的应用程序数据文件夹。:-)

于 2008-11-06T12:04:43.723 回答
3

如果您正在开发一个新应用程序并且您关心可移植性，那么您不应该将数据存储在 Windows 注册表中，因为其他操作系统没有（Windows）注册表（duh note - 这可能很明显，但经常被忽视）。

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

于 2008-11-06T12:16:37.677 回答
2

有点跑题了，但是因为我看到人们关心可移植性，所以我用过的最好的方法是 Qt 的 QSettings 类。它抽象了设置的存储（Windows 上的注册表、Mac OS 上的 XML 首选项文件和 Unix 上的 Ini 文件）。作为该课程的客户，我不必花费脑力思考注册表或其他任何事情，它就可以正常工作（tm）。

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

于 2008-11-06T12:48:43.027 回答
0

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

如果我查看我的 Document and Settings 文件夹，我会看到很多使用 Unix 点符号来设置文件夹的软件： .p4qt .sqlworkbench .squirrel-sql .SunDownloadManager .xngr .antexplorer .assistant .CodeBlocks .dbvis .gimp-2.4 .jdictionary .jindent .jogl_ext （等）

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

于 2008-11-06T12:12:04.690 回答
0

我相信 Windows 注册表是一个好主意，但是由于应用程序开发人员的大量滥用以及 Microsoft 不鼓励/强制执行的标准策略，它变成了一个无法管理的野兽。由于您提到的原因，我讨厌使用它，但是在某些情况下使用它是有意义的：

  • 卸载应用程序后留下应用程序的痕迹（例如，记住用户的偏好，以防再次安装应用程序）
  • 在不同的应用程序之间共享配置设置 - 组件
于 2008-11-06T12:55:10.157 回答
0

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

于 2008-11-06T13:51:32.977 回答
0

在 .NET 中确实不需要。

下面是 2 个示例，展示了如何使用 Project 属性来执行此操作。

这些示例通过 Windows 用户项目属性执行此操作，但应用程序也可以/可以执行相同操作。

更多在这里：

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

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

于 2008-12-29T20:00:21.937 回答
0

（讨论晚了，但是）简短的回答：组策略。

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

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

于 2014-04-25T15:31:44.337 回答