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 _＆lt; configuration＆gt;`。

结尾的所有文件

所以现在我将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根目录中的文件。文件结构类似于：

ADDED：这是源代码控制结构的外观，部署的应用程序只有配置目录，没有子文件夹或课程

\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

您可以使用构建事件来管理您的网络配置。 Hanselman有一篇很好的文章。

基本上，您在解决方案中拥有所有不同的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)"/>

Answer 4

我使用method explained by Scott Hanselman（他解释得比我能重现的要好得多，所以请点击链接:)）它对我来说很好......

Answer 5

我使用此工具：xmlpreprocess

我们为部署脚本合并的每个环境维护单独的“属性”文件。

Answer 6

我喜欢使用构建任务来automate更改所需环境的配置文件。

Answer 7

我们在配置文件中使用标记，这些标记在构建时被替换以反映预期的部署环境。我受到了Lavablast blog

的启发

只有一个模板配置文件可以管理。

缺点是您不能轻易拥有自定义“部分”。

Answer 8

老问题，但由于它在Google搜索中排名较高，我认为添加web.config transformation syntax has been available since VS2010是个好主意。使用此工具，您可以为不同的构建（调试/发布）提供不同的web.config文件

以下是关于如何使用两个连接字符串的简短摘要 - 一个用于开发（调试模式），另一个用于生产（发布模式）：

1-在web.config文件中设置开发连接字符串。看起来应该类似于：

 <connectionStrings>
    <add name="myConnectionString"  connectionString="Data Source=TestDBServer; (etc...)" />
  </connectionStrings>

2-展开您的web.config文件并打开web.release.config

3-使用Replace function将连接字符串替换为您要生产的连接字符串。在此示例中，您可以使用xdt:Locator="Match(name)"属性将其与连接字符串（myConnectionString）的名称进行匹配：

<connectionStrings>
    <add name="myConnectionString"  xdt:Transform="Replace" xdt:Locator="Match(name)" 
         connectionString="Data Source=ProdDBServer; (etc...)" />
  </connectionStrings>

4-通过右键单击web.release.config文件并选择预览转换，预览将在发布版本期间使用的web.config文件的转换。

Answer 9

我传统上使用了你提到的多个web.configs。这可能是一种痛苦，但它可以通过BeyoneComapare2或KDIff等文件比较工具来缓解......

Answer 10

烦恼：

我在我的第一次更新中提到了我的小cmd行应用程序来合并XML文档...好吧，我只是使用XmlDocument，最后只是.Save（）它到FileStream。

不幸的是，节点实际上没有任何特定的顺序，显然，.NET 需要＆lt; configSections＆gt; element是文档的第一个子元素。

我认为所有这些花哨的工具都应该让编程生活更容易？

Answer 11

我最喜欢的两种解决方法是：

一个。保留目标计算机上的设置* - 例如，在Azure中，您可以设置将覆盖web.config中的值的应用程序设置和连接字符串。（* - 或者如果您的基础架构配置是动态的，则定位目标机器。）

B中。使构建/部署工具（TeamCity，Octopus Deploy等，VS Team Services）注入特定于环境的值作为构建和/或部署的一部分。现代工具支持敏感设置的加密。

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

11 个答案: