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

Question

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

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

维护单个副本Web.Config是一件痛苦的事,因为添加新的Web服务意味着编辑多个文件并使它们保持同步.

我也注意到,如果你Web.Config手工捣乱太多,如果你尝试使用"添加项目"向导,比如为WCF添加一个新的Web服务,Visual Studio将会窒息,因为它必须修改Web .Config添加端点,nd不能解析它.所以我必须小心不要使现有的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>

然后运行我的命令行工具,并传入配置(Debug,Release,custom ...)并将合并所有以_All" or_ <configuration>` 结尾的文件.

所以现在我将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之类的工具来管理配置文件(以及构建,测试,数据库脚本等...)

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>
.
.
.

因此,如果我们要部署到发布区域,构建工具将只有一个操作,用相应区域文件夹中的文件替换config根目录中的文件.文件结构类似于:

增加:这是源控件结构的外观,部署的应用程序只有配置目录,没有子文件夹或课程

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

它非常干净,并且由任何自动构建工具(复制/替换文件)支持.好的副作用是开发人员可以创建不同的风格并将其保持在源代码控制之下,而不会影响"真正的"配置.

Answer 2

您可以使用构建事件来管理Web配置.汉塞尔曼有一篇很好的文章.

基本上,您在解决方案中拥有所有不同的web.config,然后创建(某些)新的构建类型.根据您运行的构建类型,web.config将被复制到引用的类型上!

Answer 3

您想要MSBuildCommunityTasks中的XmlMassUpdate任务(执行您尝试使用xml控制台应用程序执行的操作)

http://msbuildtasks.tigris.org/

像这样使用它

  <XmlMassUpdate Condition=" '@(ConfigTemplateFile)'!='' And '@(ConfigSubstitutionsFile)'!=''"
    ContentFile="@(ConfigTemplateFile)"
    SubstitutionsFile="@(ConfigSubstitutionsFile)"
    MergedFile="@(ConfigFile)"
    ContentRoot="/configuration"
    SubstitutionsRoot="/configuration/substitutions/$(Configuration)"/>