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

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

最常见的是：

• 网络服务器 (IIS)
• 数据库（SQL）

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

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

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

如果我们可以的话那就太好了

• web.config
• web.machine.config

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

就像..也许有：

• web.base.config
• web.machine.config

并拥有一个通过合并它们来创建 web.config 的构建脚本？

提前致谢， 史蒂芬.

edit

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

http://blogs.msdn.com/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx 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 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 在拥有一个更友好的版本方面确实会有所帮助。

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

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

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

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

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

这样我们就创建了信息的“封装”，并且可以轻松处理诸如源代码控制、部署等信息的问题。