问题标签 [configuration-files]

我正在使用应用程序范围的设置来存储在运行时无法更改的设置。我正在使用用户范围的设置来让个人用户配置他们的偏好。但是，我应该如何存储/控制在运行时可由应用程序范围内的管理员级用户修改的设置（即，它们会影响所有 PC 用户）？我想管理员可以手动修改应用程序范围的设置，但这并不可取。

谢谢！

我应该什么时候使用 .resx 文件，什么时候使用 .config 文件？

两者在使用方面的基本区别是什么？

如果我的配置文件（我提供自己的配置）是正确的，而无需针对 Xml Schema 进行验证，有什么方法可以检查 .net？

我以前听过一些关于使用关系数据库与电子表格的真正争论。关系数据库提供快速报告和（相对而言）可靠的数据仓库，其中电子表格是轻量级的、快速复制的，并且易于在组织中浮动到不同的受众。尽管我注意到两者的优点，但我很少能区分在哪种情况下哪个更好，并且总是最终使用数据库。

在开发中，当可以将配置设置放在数据库中时，很容易忘记考虑其他选项。我遇到过很多应用程序，其中用户菜单、工作流程及其顺序以及常量是在数据库级别定义的。如果最终用户从应用程序级别更改这些实体，这很好，但情况并非如此。

那么，您对数据库、配置文件和电子表格的角色有何看法？

我需要在 PHP 中存储一堆配置信息。

我考虑了以下......

这就是我到目前为止所想到的。我打算将此配置信息导入到我的应用程序中require /config.inc.php。

在存储配置数据方面什么对您有用，什么是最佳实践？

有没有人知道在编译时让 Visual Studio 完全忽略文件的方法？我有一个 C# 解决方案，它有一个 foo.config 文件，它不是真正的标准配置文件——它只是一个文本文件。在编译过程中，VS 会抓住文件和炸弹。

我想让它表现得好像它只是一个文本文件。我没有更改文件名的选项。

编辑：请注意 BuildAction 不会从编译器中排除文件检查它们。它只是决定文件是否被编译到程序集中，它是否是内容（如 jpg 或其他东西），或者它是否是资源文件。有关详细信息：请参阅 MSDN 页面。

EDIT2：显然，如果您有一个名为 foo.config 的文本文件并且在构建时将其打开，VS2005 会弹出一个错误，认为该文件应该是 xml。但是，如果您关闭该文件，VS2005 将忽略它。

解决方案：如果在构建期间打开了不合规的文件，Visual Studio 验证会导致错误。有关如何关闭此功能的示例（对于 HTML），请参阅Scott Guthrie 的帖子。正如艾伦所说，您还应该将 Build Action 设置为“None”。不幸的是，如果您打开文件，这不会停止构建错误。

如果不讨论 EntLib 日志记录块的优点或其他方面，有什么方法可以在运行时更改它的配置？

例如，我将块配置为将常规事件记录到平面文件，将关键事件记录到事件日志。
有什么方法可以更改它以将常规事件记录到控制台等，而无需重新启动我的应用程序？

澄清：我正在编写一个长时间运行的服务器应用程序。我希望能够临时增加各种日志记录组的详细程度/输出以进行诊断/故障排除，而无需重新启动应用程序。重新启动不是一种选择，因为这意味着生产中的“站点停机”。

如果我有一个新建项目，使用基于 Perl 的配置模块的最佳实践是什么？

将有一个 Catalyst 应用程序和一些命令行脚本。它们应该共享相同的配置。

我想我想要的一些功能......

分层配置以干净地维护不同的开发和实时设置。

我想定义一次“全局”配置（例如，results_per_page => 20），让那些继承但可以被我的开发/实时配置覆盖。

当我将项目部署到新服务器或将其分支/分叉/复制到新的地方（例如，新的开发实例）时，我想（仅一次）设置要使用的配置集/文件，然后是所有未来的更新是自动的。

我设想这可以通过符号链接来实现：

那么在未来

我还想要类似于 FindBin 的东西，这样我的配置可以使用绝对路径，或者相对于当前部署。给定

其中 /home/me/development/project/etc/config 包含：

当我的 perl 代码查找 tmpl_dir 配置时，它会得到：

但是在实时部署中：

相同的代码会神奇地返回

应该尊重配置中的绝对值，以便：

在所有情况下都会返回“/etc/apache2/httpd.conf”。

除了 FindBin 风格的方法，替代方法可能是允许根据其他配置值定义配置值？

我也想要一匹小马；）

一段时间以来，我一直在考虑配置文件及其与代码的关系，并且根据日期和风向，我的观点似乎会发生变化。尽管我越来越多地回到我在学习 Lisp 时最初的认识：数据和代码之间几乎没有区别。这对于配置文件来说似乎是双重的。从正确的角度来看，Perl 脚本只不过是 perl 的配置文件。这往往会对 QA 和分工（例如谁应该负责更改配置文件）等任务产生相当严重的后果。

从配置文件到成熟语言的转变通常很慢，并且似乎是由拥有通用系统的愿望驱动的。大多数项目一开始看起来很小，只有一些配置项，比如在哪里写日志、在哪里查找数据、用户名和密码等。但随后它们开始增长：功能开始能够打开或关闭，操作的时间和顺序开始被控制，并且，不可避免地，有人想要开始添加逻辑（例如，如果机器是 X，则使用 10，如果机器是 Y，则使用 15）。在某个时刻，配置文件变成了一种特定领域的语言，而且是一种写得很糟糕的语言。

既然我已经开始着手搭建舞台，以下是我的问题：

1. 配置文件的真正目的是什么？
2. 是否应该尝试保持配置文件简单？
3. 谁应该负责对他们进行更改（开发人员、用户、管理员等）？
4. 它们是否应该受到源头控制（见问题 3）？

正如我之前所说，我对这些问题的回答不断变化，但现在我在想：

1. 允许非程序员快速改变大量行为
2. 是的，任何不是粗粒度的都应该在代码中
3. 用户应该对配置文件负责，程序员应该对配置文件和代码之间的配置层负责，它可以对应用程序进行更细粒度的控制
4. 不，但更细粒度的中间层应该是

我使用 FitNesse 作为功能测试框架。当 FitNesse 运行需要配置的代码时，我遇到了麻烦。

如果我需要从配置文件中获取连接字符串，我可以通过将其添加到 FitServer.exe.config 来使其工作。但是，我不喜欢这种解决方案。我希望 FitNesse 加载我自己的配置文件，即 TheNameOfMyApp.dll.config。

这可能吗？