您如何处理多个环境的多个 web.config 文件？答案

【问题标题】：How do you handle multiple web.config files for multiple environments?您如何处理多个环境的多个 web.config 文件？
【发布时间】：2010-10-10 05:03:55
【问题描述】：

我目前处理这个问题的方式是拥有多个配置文件，例如：

web.config
web.Prod.config
web.QA.config
web.Dev.config

当项目部署到不同的环境时，我只需使用正确的设置重命名相应的文件。

有人对如何更好地处理这个问题有建议吗？

编辑：以下是每个配置中的一些变化：

WCF 客户端端点 URL 和安全性
自定义数据库配置
会话连接字符串
log4net 设置

【问题讨论】：

我就是这么干的，只不过web.config和web-dev.config是一回事。

标签： c# asp.net web-applications

【解决方案1】：

这实际上取决于导致您使用不同 web.config 文件的环境之间的差异。您能否提供更多信息，说明为什么每个环境目前都需要不同的环境？

【讨论】：

我想每个环境都需要专门的数据库连接、状态服务配置和其他各种可配置的项目，这些项目在很大程度上取决于您所处的环境。

【解决方案2】：

我们一直这样做的方式是覆盖 AppSettings 部分：

<appSettings file="../AppSettingsOverride.config">
    <add key="key" value="override" />    
    ...
</appSettings>

这仅适用于 appSettings 部分，因此仅在一定程度上有用。我会对更强大的解决方案非常感兴趣。

在下面编辑

刚刚看了这个： http://channel9.msdn.com/shows/10-4/10-4-Episode-10-Making-Web-Deployment-Easier/

VS2010 的配置转换看起来非常棒，应该让多个配置变得轻而易举。

【讨论】：

这很有趣——您是否也在源代码管理中管理每个 AppSettingsOverride.config 文件？使用您的方法和使用单独的 web.config 文件有什么区别？
最大的好处是每个开发者都可以有自己的覆盖设置。源代码控制中的 web.config 中的内容是我们想要在主部署环境中使用的内容，并且我们在开发和测试服务器上进行了覆盖。我可能会将其与已经说过的最佳效果结合起来。

【解决方案3】：

在 Visual Studio 中，我创建 xcopy 构建事件并将所有配置文件存储在 /config 文件夹中。如果在构建配置之后命名文件，则所有配置只需要一个事件：即用 /config/web.$(Configuration).config 覆盖 web.config

【讨论】：

【解决方案4】：

我们有一些变通方法（并非所有方法都使用 web.config 完成，但想法相同）

我们在打包的部署中包含多个配置文件。在安装过程中，我们会指定要安装的环境。
将所有环境特定设置迁移到该环境的数据库服务器。 WebServer 在请求服务器名称时提供其环境
提供多个设置（每个环境 1 个）并使用代码请求不同的设置。
2 和 3 的组合（根据环境覆盖部分设置 - 例如应用程序服务器名称）

【讨论】：

【解决方案5】：

Scott Gu 曾经在此发过article。他提出的解决方案是使用 Pre-build 事件根据选择的构建配置将正确的配置复制到适当的位置。

我还注意到 SO 上已经有一个类似的question。

【讨论】：

【解决方案6】：

通过大多数不同的版本管理软件（subversion、git 等），您可以忽略特定文件。

因此，在颠覆中，我会：

configure.template.php - 这个文件是版本化的并且包含模板化的配置数据，例如空的 DSN configure.php - 忽略此文件，因此不会跟踪对它的更改。

在颠覆中，这样做的方法是：

svn pe svn:忽略。它会打开你的编辑器，然后你输入配置.php

保存、退出、签入您的更改，然后就可以开始了。

【讨论】：

【解决方案7】：

我最喜欢的解决方法是使用configSource 属性。诚然，我只在一个元素 (<connectionStrings>) 上使用它，但它确实提供了一种简单的方法来换入和换出 web.config 的不同部分（我在安装期间通过 WebSetup 项目执行此操作）。

【讨论】：

【解决方案8】：

我也使用 web.DEV.config、web.TEST.config、web.PROD.config 等。

如果您的项目并不复杂，我发现这种方式是最简单、最简单、最直接的方式。我不喜欢让事情变得过于复杂。

但是，我使用了 NAnt，我认为它对此非常有效。您可以为不同的环境设置构建。 NAnt 需要阅读一些资料来学习如何使用它，但它非常灵活。

http://aspnet.4guysfromrolla.com/articles/120104-1.aspx

http://nant.sourceforge.net/

我将它与 CruiseControl.net 和 NUnit 一起使用，通过单元测试验证执行自动日常构建，并认为它们可以很好地协同工作。

【讨论】：

【解决方案9】：

变换似乎对此很有帮助。您可以用不同的规则替换某些部分。

http://msdn.microsoft.com/en-us/library/dd465318(v=vs.100).aspx

【讨论】：