Question

我确信每个人都必须处理这些情况，我们检查我们的源控制解决方案，每个开发机器都有自己的资源用于调试，构建和测试..

最常见的是：

Web服务器（IIS）
数据库（SQL）

Web服务器易于处理，每台开发机器都有自己的proj.user文件来指定不同的调试信息。

但应用程序的连接字符串存储在web.config（受源代码管理）下，理想情况下我们不希望web.config“知道”，因此必须在我们委派它们的地方执行配置部分到其他配置文件（不在sc下）不是最好的解决方案..

asp.net（.net？）已经支持一个具有web.config继承的模型，这将是一个理想的场景..但是这仅适用于目录。

如果我们能够拥有

那就太好了

web.config＆lt; - 在版本控制下
web.machine.config＆lt; - 不受版本控制

当然，我愿意为人们如何解决这个问题提供更好的建议。

喜欢..也许有：

web.base.config＆lt; - 在版本控制下
web.machine.config＆lt; - 不受版本控制

有一个构建脚本通过合并创建web.config吗？

提前致谢，斯蒂芬。

修改

看起来下一个vs可能有办法解决这个问题：

http://blogs.msdn.com/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx

修改编辑

今天可以通过xml批量更新来实现：

http://blogs.microsoft.co.il/blogs/dorony/archive/2008/01/18/easy-configuration-deployment-with-msbuild-and-the-xmlmassupdate-task.aspx

修改编辑

那么它当然可以用简单的xslt构建任务和一个复制所有内容并拦截某些属性的小变换。只是尝试了一个概念验证，这将为我们节省很多挫折，但转换文件可能更多人们愿意接受。

基本上我们在版本控制中存储Web.base.config，并通过转换运行它以在构建事件上生成Web.config。

似乎vs2010对于拥有更加友好的版本非常有帮助。

Answer 1

我有时使用的一种方法是将特定于环境的部分分解为单独的配置文件，这些部分通常从部署中排除（第一次或者结构更改除外）：

连接字符串示例：在web.config中：

<connectionStrings configSource="connections.config"></connectionStrings>

connections.config文件（通常不包含在部署中;因此它保持不变）：

<?xml version="1.0"?>
<connectionStrings>
    <add name="connectionName" connectionString="[connection string goes here]"/>
</connectionStrings>

就像我们已经创建了信息的“封装”，并且可以轻松地处理源控制，部署等信息。

Answer 2

虽然肯定有很多解决方案，但它们都没有真正让你对生成的配置进行大量控制，我在编辑中注意到了一个解决方案，你可以获得大量的控制但是需要花费大量的开销。编写一个xslt文件，使用xslt构建任务从源代码控制中使用模板web.config / app.config（我个人将其命名为web.base.config / app.base.config），并使用xslt文件进行转换在构建时控制配置文件的版本，并生成web.config / app.config。

以下是xslt build task的示例（尽管您可能希望将其编写为您自己的编码标准），以及一个普通的xslt转换示例，它将更改连接字符串的值并复制其他所有内容在配置中：

<?xml version="1.0" encoding="utf-8"?>  
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" exclude-result-prefixes="msxsl">  
  <xsl:output method="xml" indent="yes"/>  

  <!-- Copy all. -->  
  <xsl:template match="@* | node()">  
      <xsl:copy>  
          <xsl:apply-templates select="@* | node()"/>  
      </xsl:copy>  
  </xsl:template>  

  <!-- Swap connection string. -->
  <xsl:template match="/configuration/connectionStrings/add[@name='my_connection_string_name']">
    <xsl:copy>
      <xsl:apply-templates select="@* | node()"/>
      <xsl:attribute name="connectionString">my replacement connection string value</xsl:attribute>
    </xsl:copy>  
  </xsl:template>

</xsl:stylesheet>

这是一个平庸的例子，但是你可以想象你可以完全转换以前在基于继承的场景中遇到困难的整个部分。

Answer 3

应用程序的配置可以分为两类。

特定于应用程序
特定部署

特定于应用程序的配置包括缓存实现，业务规则实现等内容，并将应用于应用程序的每个部署。这应该进入web.config文件，该文件是应用程序目录结构的一部分，并被检入源代码管理。

部署特定配置包括连接字符串，超时期限等内容，并且可能因部署而异。这应该作为部署中涉及的IIS实例的配置的一部分输入，并由相关机器的任何备份策略保留。

据我所知，这正是web.config文件的层次结构本质所要处理的。

这种安排的好处是......

无需担心哪些开发人员的设置版本最终会在源代码管理中出现，因为它们都没有。
每个部署都使用相同的二进制文件，因此部署问题更有可能涉及部署配置。
后续部署不需要特定于部署的配置更改，因为它们已经到位。

Answer 4

VS 2010将为您提供大量控制来管理各种配置的web.config文件...... Please check out。

Answer 5

我们不在web.config中存储环境设置。它们存储在数据库中。

这使我们能够进行xcopy部署，并将web.config文件存储在我们的版本控制系统中。

通过一个注册表项访问数据库。

Answer 6

您所描述的内容听起来很像使用Machine.config文件来存储连接字符串。我还没有看到这个，所以你试过吗？看起来您可以使用位于Machine.config旁边的全局Web.config。

一些链接：

ASP.NET Configuration File Hierarchy and Inheritance

Difference between Web.config and Machine.config

使用版本控制时，处理多台计算机上的web.config差异

6 个答案: