我想知道存储配置设置的一些最佳实践。假设您在多个应用程序中共享了一些设置。我听说过存储这些需要共享的设置（XML文件）的好方法和坏方法。
只是想知道在跨构建维护应用程序设置方面的优秀标准是什么，以便于部署。
我想我正在从两种情况看这个：
添加-1 ：
感谢。我听说过恐怖故事，有些地方在多个应用程序中管理配置设置。我不是一个构建人，所以我不知道为什么，但我想确保我现在理解它在web.config与自定义配置文件等方面的类型。
添加-2 ：
当您创建要使用的API时，该怎么办？你可以说一个类会提取某些配置信息，但是在客户端使用你的API（特别是C＃/ .NET）之前，这些端点（属性）没有定义？你在哪里以及如何设置这些属性让我们说你创建的配置类如“ApplicationDefinitions”？
答案 0 :(得分：1)
如果它跨越多个应用程序，您可以（非常小心地）将设置放入machine.config。
或者，您可以拥有一个单独的公共配置设置存储库文件，该文件可以在每次构建Web应用程序/解决方案时读入并用于生成新的web.config。
答案 1 :(得分：1)
我们必须支持多个UAT（用户验收测试），生产，开发和灾难恢复环境。
理想情况下，这些信息都将存在于一个巨大的LDAP服务器中。
在现实世界中，我们编写了一个使用Jakarta-Velocity作为模板引擎的ANT任务。这将从单个模板文件生成多个文件（UAT，DEV，PROD，DR）。
我们有一个中央文件，用于所有常见内容和单个应用程序的较小文件。任何一个应用程序的命令行需要知道它是否是正在运行的UAT / DEV ..系统等，然后加载到公共文件和特定于应用程序的文件中。
这在实践中非常有效，我们已经使用了大约8年。我见过很多其他人试图在他们所有的环境中处理多个应用程序文件而且它并不漂亮。经常会犯错误。
答案 2 :(得分：0)
我尝试将将不同环境部署的配置设置分离为单独的文件，按逻辑功能组织，然后不在部署脚本中包含这些文件......
如果你在.Net中编码，那么多个应用程序中的共同设置可以存储在machine.config中...再次，不要将它们直接放在machine.config中，而是创建对a的引用单独的文件（使用自定义的configSection和configSource =“”属性，以创建对该单独文件的间接引用...