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

Question

有人知道有什么好的工具/实用程序可以在不同的构建/部署环境之间管理 Web.Config 文件吗？

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

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

我还注意到，如果您手动过多地修改 Web.Config，当您尝试使用“添加项目”向导(例如添加一个项目)时，Visual Studio 就会卡住。 WCF 的新 Web 服务，因为它必须修改 Web.Config 来添加端点，并且无法再解析它。所以我必须小心不要使现有的 Web.Config 无效。

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

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

<小时/>

更新:

我决定编写一个快速控制台应用程序，它将获取给定目录中的所有 xml 文件并将它们合并为一个，并且仅根据名称包含某些文件。

所以我可以在目录中创建:

WebConfig_All

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

connectionStrings_Debug

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

connectionStrings_Release

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

然后运行我的命令行工具，并传入配置(调试、发布、自定义...)它将合并所有以 _All"或 _ ` 结尾的文件。

现在，我的 Web.Config 的 80% 位于单个 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 的工具管理配置文件(以及构建、测试、数据库脚本等...)

Answer 1

我们将所有区域特定设置拆分到他们自己的配置文件中。在 Web 应用程序的根目录下，我们创建一个配置文件夹并将区域特定设置放在那里。因此，配置根目录下的任何文件都会被拾取。

我们的 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>
.
.
.

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

添加:这就是源代码控制结构的外观，部署的应用程序只有配置目录，没有子文件夹或类(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

它非常干净，并且受到任何自动化构建工具的支持(复制/替换文件)。好的副作用是开发人员可以创建不同的风格并将它们置于源代码控制之下，而不会影响“真实”配置。