.net - 在部署环境之间管理复杂的Web.Config文件

有谁知道在不同的构建/部署环境之间管理Web.Config文件的任何好的工具/实用程序？

例如，我有一个WCF项目，在开发中我不想启用SSL，但确实希望在生产中启用它。我想要不同的日志记录设置，不同的数据库连接字符串，不同的错误处理，不同的文件路径...甚至是一些不同的Unity框架绑定(bind)(为单元测试而不是为部署实际对象而连接模拟程序)。

维护Web.Config的单个副本很麻烦，因为添加新的Web服务意味着要编辑多个文件并使它们保持同步。

我还注意到，如果您过多地手动处理了Web.Config，如果您尝试使用“添加项目”向导为WCF添加新的Web服务，则Visual Studio将感到窒息，因为它必须修改WCF。 Web.Config添加端点，并且无法再解析它。因此，我必须注意不要使现有的Web.Config无效。

我还考虑过仅使用一些正则表达式进行替换，并仅在预构建命令中构建新的Web.Config。到目前为止，这似乎是最好的选择...

还有其他想法吗？看来这应该是一个非常普遍的问题，因为开发和生产部署之间的Web.Config可能永远不会相同。

更新:

我决定编写一个快速的控制台应用程序，它将所有XML文件放在给定目录中，并将它们合并到一个目录中，并且仅包含基于名称的某些文件。

所以我可以在目录中:

WebConfig_所有

<configuration>
  <configSections>
    ...
  </configSections>
  <system.web>
    ...
  </system.web>
</configuration>

connectionStrings_Debug

<configuration>
  <connectionStrings>
    <add name="connstr" connectionString="...dev..." />
  </connectionStrings>
</configuration>

connectionStrings_发布

<configuration>
  <connectionStrings>
    <add name="connstr" connectionString="...prod..." />
  </connectionStrings>
</configuration>

然后运行我的命令行工具，并传入配置(Debug，Release，custom ...)
它将合并所有以_All" or _ `结尾的文件。

因此，现在我将80.％的Web.Config保存在单个WebConfig_All文件中，并将每个构建配置的20％定制内容保存在单独的文件中。然后，我可以在VisualStudio中，从NAnt或任何我想运行的地方，将命令行工具作为预构建任务运行...

我还使我的XML合并逻辑足够好来处理以下内容:

<x>
  <y a="1">
    <z a="1"/>
  </y>
</x>

合并

<x>
  <y a="1">
    <z a="2"/>
  </y>
  <y a="2"/>
</x>

结果是:

<x>
  <y a="1">
    <z a="1"/>
    <z a="2"/>
  </y>
  <y a="2"/>
</x>

到目前为止看起来不错... :)

跟进:

这个主题现在有点老了，所以我想指出，VisualStudio 2010具有内置的执行web.config转换的功能:http://msdn.microsoft.com/en-us/vstudio/Video/ff801895

当然，以典型的Microsoft方式(仅以50％的方式实现任何功能)，它仅适用于使用Web部署的Web项目。有一个插件可以启用其他项目中的转换，位于:http://www.hanselman.com/blog/SlowCheetahWebconfigTransformationSyntaxNowGeneralizedForAnyXMLConfigurationFile.aspx

您还可以使用BuildMaster之类的工具来管理配置文件(以及构建，测试，DB脚本等)。

最佳答案

我们将所有特定于区域的设置拆分为自己的配置文件。在Web应用程序的根目录下，我们创建一个config文件夹，并将区域特定的设置放在此处。因此，位于config根目录下的所有文件都会被拾取。

我们的web.config看起来像:

.
.
.
<appSettings configSource="config\appSettings.config"/>
<nlog configSource="config\nlog.config"/>
<applicationSettings>
    <MyApp.UI.Properties.Settings configSource="config\Settings.APGUI.config"/>
    <MyApp.BusinessServices.Properties.Settings configSource="config\Settings.Business.config"/>
    <MyApp.Auditing.Properties.Settings configSource="config\Settings.Auditing.config"/>
</applicationSettings>
.
.
.

因此，如果我们要部署到发布区域，则构建工具将只执行一个操作，即用相应区域文件夹中的文件替换config根目录中的文件。文件结构如下所示:

添加:这是源代码管理结构的外观，已部署的应用程序仅具有配置目录，没有子文件夹或类(class)

\Root
   web.config
   \Config
       appsettings.config
       services.config
       logging.config
       \release
          appsettings.config
          services.config
          logging.config
       \debug
          appsettings.config
          services.config
          logging.config

它非常干净，并且受任何自动构建工具(复制/替换文件)的支持。好的好处是，开发人员可以创建不同的样式并将其保留在源代码控制下，而不会影响“实际”配置。