何时以及为什么要将数据存储在Windowsregistry中？
作为一名开发人员，在registry中存储configuration/选项的工具是我生活中的祸根。 我不能轻易跟踪这些选项的变化，不能轻易地将它们从一台机器移植到另一台机器，这一切都让我真正渴望.INI文件的美好时光。
在编写自己的应用程序时，我应该select放入registry而不是旧式的configuration文件，为什么？
- 最初（WIN3）configuration存储在Windows目录中的WIN.INI文件中。
- 问题：WIN.INI变得太大了。
- 解决scheme（Win31）：与程序位于同一目录中的单个INI文件。
- 问题：该程序可能安装在networking上，并被许多人共享。
- 解决scheme（Win311）：用户的Window目录中的单个INI文件。
- 问题：许多人可能共享一个Windows文件夹，它应该是只读的。
- 解决scheme（Win95）：registry，每个用户都有独立的部分。
- 问题：registry变得太大了。
- 解决scheme（WinXP）：将大量单个数据移动到用户自己的Application Data文件夹中。
- 问题：适用于大量数据，但对于less量数据则相当复杂。
- 解决scheme（.NET）：在与应用程序相同的文件夹中的.config（Xml）文件中存储less量固定的只读数据，并使用API读取它。 （读/写或用户特定的数据保留在registry中）
从用户angular度和程序员的angular度来看，我不得不说，除非像文件关联或机器特定的设置那样，否则在registry中放入某些东西真的不是一个好的优点。
我来自学校，认为程序应该可以从安装的任何地方运行，安装应该完全可以在机器内移动，甚至可以移动到另一台机器上，而不会影响程序的运行。
任何可configuration的选项或必需的dll等（如果它们不是共享的话）应驻留在安装目录的子目录中，以便整个安装很容易移动。
我使用了很多像程序这样的小工具，所以如果它不能被安装在USB棒上，插在另一台机器上运行，那么它不适合我。
微软政策：
- 在Windows 95之前，我们使用ini文件来处理应用程序数据。
- 在Windows 95 – XP时代，我们使用registry。
- 从Windows Vista中，我们使用ini文件，虽然他们现在是基于xml的。
registry是机器相关的。 我从来没有喜欢它，因为它变得缓慢，几乎无法find你需要的东西。 这就是为什么我喜欢简单的ini或其他设置文件。 你知道他们在哪里（应用程序文件夹或用户文件夹），所以他们很容易移植，并且可读。
何时 – 由于遗留系统集成，或者客户的系统pipe理员说“应该是这样”，或者因为您正在使用较旧的语言进行开发，这使得使用XML变得更加困难。
为什么 – 主要是因为registry不像复制坐在应用程序旁边的configuration文件（并且几乎是相同的）。
如果你使用的是.Net2 +，你已经得到了App.Config和User.Config文件，你不需要在registry中注册DLL，所以远离它。
configuration文件有自己的问题（见下文），但是这些可以编码，你可以改变你的架构。
- 问题：应用程序需要可configuration的设置。
- 解决scheme：将设置存储在Windows文件夹中的文件（WIN.INI）中 – 使用节标题对数据进行分组（Win3.0）。
- 问题：WIN.INI文件变得太大（并且变得杂乱）。
- 解决scheme：将INI文件中的设置存储在与应用程序（Win3.1）相同的文件夹中。
- 问题：需要用户特定的设置。
- 解决scheme：将用户设置存储在用户的Windows目录（Win3.11）中的特定用户INI文件或应用程序INI文件中的用户特定部分。
- 问题：安全性 – 某些应用程序设置需要是只读的。
- 解决scheme：具有安全性的registry以及用户特定的和机器范围的部分（Win95）。
- 问题：registry变得太大了。
- 解决scheme：用户特定的registry移动到用户自己的“应用程序数据”文件夹中的user.dat，并且仅在login时（WinNT）加载。
- 问题：在大型企业环境中，您login到多台计算机，必须设置EACH ONE。
- 解决scheme：区分本地（本地设置）和漫游（应用程序数据）configuration文件（WinXP）。
- 问题：xcopy无法像.NET的其余部分一样部署或移动应用程序。
- 解决scheme：APP.CONFIG XML文件与应用程序在同一文件夹中，易于阅读，易于操作，易于移动，可跟踪如果更改（.Net1）。
- 问题：仍然需要以类似（即xcopy部署）的方式存储用户特定的数据。
- 解决scheme：用户本地或漫游文件夹中的USER.CONFIG XML文件和强types（.Net2）。
- 问题：CONFIG文件区分大小写（对人不直观），需要非常特定的打开/closures“标签”，连接string不能在运行时设置，安装项目不能写入设置（像registry一样容易），不能轻易确定user.config文件和用户设置随每个新版本安装。
- 解决scheme：使用ITEM成员在运行时设置连接string，在安装程序类中编写代码以在安装期间更改App.Config，并在未find用户设置时将应用程序设置用作默认值。
如果您在Windowsregistry中存储了几个窗口位置和最近使用的项目列表，世界是否会结束？ 到目前为止我的工作很好。
HKEY-CURRENT-USER是存储小量用户数据的好地方。 这就是它的目的。 仅仅因为其他人滥用了它，它似乎很愚蠢。
除非您真的想要亲自查找用户的“应用程序数据”文件夹，否则您希望在用户的漫游configuration文件中可用的设置应该放在registry中。 🙂
registry读写是线程安全的，但文件不是。 所以这取决于你的程序是否是单线程的。
如果你正在开发一个新的应用程序，你关心的可移植性，你应该永远不要将数据存储在Windowsregistry，因为其他操作系统没有（Windows）registry（注意 – 这可能是显而易见的，但经常被忽视）。
如果你只是开发Win平台，尽量避免它。 configuration文件（可能是encryption的）是一个更好的解决scheme。 将数据存储到registry中没有任何好处 – （例如，如果使用.NET，隔离存储是一个更好的解决scheme）。
稍微偏离主题，但是由于我看到关心可移植性的人们，我曾经使用过的最好的方法是Qt的QSettings类。 它抽象设置的存储（Windows上的registry，Mac OS上的XML首选项文件和Unix上的Ini文件）。 作为全class的客户，我不必花费大脑周期来了解registry或其他任何东西，它只是工作（tm）。
通常情况下，如果您不将设置放入registry中，则主要使用它来获取当前的Windows设置，更改文件关联等。
现在，如果您需要检测您的软件是否已经安装，您可以在registry中进行一个最小的input，这是您可以在任何configuration中find的位置。 或者在应用程序数据中search给定名称的文件夹。
如果我看看我的文档和设置文件夹，我看到很多软件使用Unix点符号来设置文件夹：.p4qt .sqlworkbench .squirrel-sql .SunDownloadManager .xngr .antexplorer .assistant .CodeBlocks .dbvis .gimp-2.4 .jdictionary .jindent .jogl_ext（等）
在应用程序数据中，包含编辑器名称或软件名称的各种文件夹。 看起来像当前的趋势，至less在便携式应用程序…
WinMerge使用稍微不同的方法，将数据存储在registry中，但在configuration对话框中提供了导入和导出选项。
就我个人而言，我已经使用registry来存储（un）安装脚本所使用的安装path。 我不确定这是否是唯一可行的select，但似乎是一个明智的解决scheme。 这是一个应用程序，当然只能在Windows上使用。
在.NET中真的不是一个需要。
这里有两个例子展示了如何使用Project proerties来做到这一点。
这些示例通过Windows用户项目属性执行此操作，但是Application也可以执行相同的操作。
更多在这里：
（讨论晚了）简答：组策略。
如果您的客户的IT部门想要强制执行Windows或您正在撰写或捆绑的组件（如链接速度，自定义错误消息或要连接到的数据库服务器）的相关设置，则这仍然是典型的通过组策略完成，这使得它的最终performanceforms是存储在registry中的设置。 这些策略从Windows启动或用户login时开始执行。
有一些工具可以创build自定义的ADMX模板，这些模板可以将组件的设置映射到registry位置，并为pipe理员提供一个通用接口来强制执行需要强制实施的策略，同时只向他们显示那些有意义的强制设置。
我相信Windowsregistry是一个好主意，但是由于应用程序开发人员的大量滥用，以及微软不鼓励/制定的标准政策，微软成了一个难以控制的野兽。 我讨厌使用它，因为你提到的原因，但有一些场合，它是有道理的使用它：
- 应用程序卸载后，留下一些应用程序的痕迹（例如，记住用户的偏好，以防再次安装应用程序）
- 在不同应用程序 – 组件之间共享configuration设置
