registry与INI文件存储用户可configuration的应用程序设置
我是一个新的Windows程序员，我不知道应该在哪里存储用户可configuration的应用程序设置。 我明白需要为用户提供一种用户友好的方式来更改应用程序设置，如Edit | 设置表格或类似的。 但是，在用户点击该表单上的“应用”button后，我应该在哪里存储值？
在Windowsregistry中存储设置与将其存储在本地INI文件或configuration文件或类似文件中有什么优缺点？
优点configuration文件：
- 容易做到。 不需要知道任何Windows API调用。 你只需要知道你的编程语言的文件I / O接口。
- 便携。 如果将应用程序移植到另一个操作系统，则不需要更改设置格式。
- 用户可编辑的。 用户可以在程序执行之外编辑configuration文件。
优点registry：
- 安全。 用户不会意外删除configuration文件或者破坏数据，除非他/她知道registry。 然后用户只是在寻求麻烦。
- 我不是专业的Windows程序员，但是我确定使用registry可以更轻松地完成其他特定于Windows的操作（用户特定设置，networkingpipe理等组策略等）。
如果你只需要一个简单的方法来存储configuration信息，我会推荐一个configuration文件，使用INI或XML作为格式。 我build议使用registry，只有在某些特定的情况下才能使用registry。
Jeff Atwood有关于Windowsregistry的一篇很好的文章 ，为什么最好使用.INI文件。
如果将每个应用程序的设置存储在一个我可以轻易看到的地方，操作它们并将其备份，那么我的生活会变得更加容易。 就像在INI文件中说的那样。
- registry是单点故障 。 这就是为什么你会发现每一个registry编辑提示开始与一个大胖子尖叫免责声明关于如何使用registry打破你的计算机。
- registry是不透明的和二进制的 。 尽pipe我不喜欢尖括号征税，但至lessXMLconfiguration文件是合理的人类可读的，并允许尽可能多的评论，你认为合适的。
- registry必须与文件系统同步 。 删除一个应用程序没有“卸载”它，你留下陈旧的registrycruft。 或者如果一个应用程序有一个写得不好的卸载程序。 文件系统不再是logging声明 – 它必须以某种方式与registry保持同步。 这完全违反了DRY原则。
- registry是单片的 。 假设您想将应用程序移动到您计算机上的其他path，或者甚至完全移到其他计算机上。 祝你好运从巨大的registrytarball中提取这个特定应用程序的相关设置。 一个给定的应用程序通常有几十个设置遍布registry。
根据GetPrivateProfileString的文档，您应该使用registry来存储初始化信息。
但是，如果您仍想使用.ini文件，并使用标准configuration文件API（ GetPrivateProfileString ， WritePrivateProfileString等）来访问它们，则它们提供内置的方法来自动提供“虚拟.ini文件”由registry支持。 双赢！
这里有一个类似的问题，涵盖了一些优点和缺点。
我build议不要使用registry，除非你的应用程序绝对需要它。 从我的理解，微软正试图阻止使用registry，由于设置文件的灵活性。 另外，我不推荐使用.ini文件，而是使用.Net的一些内置function来保存用户/应用程序设置。
在与应用程序相同的目录中使用ini文件，可以将其与应用程序一起备份。 所以，当你重新加载你的操作系统，你只需要恢复应用程序目录，你有你想要的configuration。
在registry中使用INI文件还有一个好处，那就是我没有看到：如果用户使用某种基于卷/文件的encryption，他们可以很容易地对INI文件进行encryption。 随着registry，它可能会更成问题。
正如Daniel所说，将configuration数据存储在registry中可让您select使用pipe理模板。 也就是说，您可以定义pipe理模板，在组策略中使用它，并在整个networking范围内pipe理您的应用程序的configuration。 根据应用程序的性质，这可能是一大福音。
我同意丹尼尔。 如果这是一个大的应用程序，我想我会在registry中做的事情。 如果它是一个小应用程序，并且您希望具有用户可configuration的方面而无需进行configuration表单，则可以使用一个快速的INI文件。
我通常这样parsing（如果.ini文件中的格式是option = value，每行一个，以＃开始的注释）：
static void Parse() { StreamReader tr = new StreamReader("config.ini"); string line; Dictionary<string, string> config = new Dictionary<string, string>(); while ((line = tr.ReadLine()) != null) { // Allow for comments and empty lines. if (line == "" || line.StartsWith("#")) continue; string[] kvPair = line.Split('='); // Format must be option = value. if (kvPair.Length != 2) continue; // If the option already exists, it's overwritten. config[kvPair[0].Trim()] = kvPair[1].Trim(); } }
编辑：对不起，我以为你已经指定了语言。 上面的实现是在C＃中。
registry已针对快速访问和轻松更新进行了优化，而且它是执行特定Windows特定事项（如与扩展关联）的唯一方法。 您可以忽略关于删除单个目录以卸载程序的说法–Windows Vista不会允许您修改Program Files目录中的文件，因此您的configuration将需要在不同的文件夹中。
Windows编程有一个通用的指导方针 – 按照微软希望的方式来做事，而你的生活将会变得更加简单。
这就是说，我可以看到INI文件的吸引力，我不会责怪任何人考虑它。
现有的答案涵盖了很多地方，但我想我会提到另外一点。
我使用registry来存储系统范围的设置。 也就是说，当2个或更多的程序需要完全相同的设置。 换句话说，一个设置由几个程序共享。
在所有其他情况下，我使用本地configuration文件，该文件与可执行文件位于同一path中，或者位于一个configuration目录下。 原因已经涵盖在其他答案（便携式，可以用文本编辑器等编辑）。
为什么把系统范围的设置放到registry中？ 那么，我发现如果一个设置是共享的，但你使用本地configuration文件，你最终重复设置。 这可能意味着你最终需要在多个地方更改设置。
例如，说程序A和程序B都指向同一个数据库。 您可以为连接string设置“系统范围”registry设置。 如果你想指向一个不同的数据库，你可以在一个地方更改连接string，现在这两个程序将运行在另一个数据库上。
注 – 如果两个或多个程序不需要使用相同的值，则以这种方式使用registry没有意义。 例如，程序A和程序B都需要一个可能相同的数据库连接string，但并不总是如此。 例如，我希望程序B现在使用testing数据库，但程序A应该继续使用生产数据库。
通过上面的例子，你可以使用一些本地configuration覆盖系统范围的设置，但是对于简单的任务它可能开始变得过于复杂。
ini或config文件有一个缺点，即如果用户可以select安装程序的位置，那么它们就是定位它们的。
您的应用程序是与安装程序一起安装的，还是只是“提取并运行”？ 在第一种情况下，请看这里列出的优点和缺点。 但是对于解压缩和运行，registry在我看来是一个“禁止”，因为人们希望能够简单地删除应用程序文件夹以摆脱您的程序。
