我在ASP.NET MVC网站上与几个朋友一起工作。该项目在SVN中维护，我设置了CC.Net以检查最新版本，并自动构建并部署到预生产服务器。默认构建配置设置为Debug，但自动构建设置为构建Retail。一切正常，除了web.config中的 <compilation debug=""> ，目前总是设置为true。我希望能够根据构建风格为 <compilation debug=""> 指定true或false。
我已经考虑过这个问题的两个独立解决方案。
我可以有一个修改价值的前/后构建步骤。但是，web.config文件受源代码控制，因此在自动构建中对其进行修改将使其在构建计算机上签出。我还可以有额外的步骤来恢复它。
我也可以在源代码控制下使用web.config，而是在构建期间使用web.config.base文件作为源来生成web.config文件。这种方法的问题是大多数工具直接修改web.config，我们必须手动将这些更改合并到基本文件中。由于没有迹象表明任何工具更改了web.config，我们必须在任何签入时查找更改。这不仅是一个繁琐的手动步骤，而且也容易出错。
这两种方法都可行，但有一些缺点。我希望有一种更优雅的方式来做到这一点。因此，问题是 - 你们如何处理在CI构建期间修改源代码控制下的web.config？
答案 0 :(得分：1)
您可以查看Web Deployment Projects VS插件。 Scott Guthrie在post中做了很好的解释。
答案 1 :(得分：0)
为什么不使用可编辑XML的命令行实用程序将web.config作为构建步骤的一部分进行修改？
e.g。获取一个类似于：
的命令行实用程序xml_mod.exe web.config [xpath-of-value-to-change] [new-value]
然后每个调试/发布（零售）具有不同的值..
答案 2 :(得分：0)
为什么不在不从源代码管理中检出web.config进行读/写，在构建过程中进行所需的更改然后丢弃它们？
AFAIK SVN无论如何都要读/写文件。
答案 3 :(得分：0)
我们有一个
这允许我们在那里放置注释以及特定于环境的值，这通常必须在某些文档中进行，并且肯定会被忽略。
就像我说的，我们在每次构建时都将Hudson部署到我们的cert环境中，因此它只是复制目录，删除web.config并将web.config.cert重命名为web.config
你可能想看看Hudson，我不认为我曾经听说有人选择CC.net而不是Hudson，如果他们有能力选择：）