CI 构建期间在源代码控制下自动更改 web.config
我正在与几个朋友一起开发 ASP.NET MVC 网站。 该项目在 SVN 中维护，我设置了 CC.Net 来检查最新版本并自动构建并部署到预生产服务器。 默认构建配置设置为“调试”，但自动构建设置为“构建零售”。 一切工作正常，除了 web.config 中的
我已经考虑过解决这个问题的两种不同的方法。
我可以有一个修改该值的构建前/构建后步骤。 但是，web.config 文件受源代码控制，因此在自动构建中修改它会使其在构建计算机上签出。 我还可以采取额外的步骤来恢复它。
我还可以不将 web.config 置于源代码控制下，而是使用 web.config.base 文件在构建过程中用作源来生成 web.config 文件。 这种方法的问题在于，大多数工具直接修改 web.config，我们必须手动将这些更改合并回基本文件中。 由于没有任何工具更改 web.config 的迹象，因此我们必须在任何签入时查找更改。 这不仅成为一个繁琐的手动步骤，而且还容易出错。
这两种方法都可行，但都有一些缺点。 我希望有一种更优雅的方式来做到这一点。 因此问题是——你们如何处理在 CI 构建期间修改受源代码控制的 web.config ？
I am working with couple of friends on an ASP.NET MVC website. The project is maintained in SVN and I have CC.Net set up to checkout latest version and do automated build and deploy to a pre-production server. The default build configuration is set to Debug, but the automated build is set to build Retail. Everything works just fine, except for the <compilation debug=""> in web.config which currently is set always to true. I'd like to be able to specify true or false for <compilation debug=""> based on the build flavor.
I've thought about two separate solutions to this problem.
I could have a pre/post-build step that modifies the value. However, the web.config file is under source control, so modifying it in the automated build will leave it checked out on the build machine. I could also have additional step that would revert it as well.
I could also instead of having web.config under source control, have a web.config.base file that is used as a source during the build to generate the web.config file. The problem with this approach is that most of the tools modify web.config directly and we have to manually merge such changes back in the base file. And since there's no indication when any tool changed web.config, we have to look for changes at any checkin. Not only this becomes a tedious manual step, but it's also error prone.
Both of these approaches would work, but have some shortcomings. I was hoping there's a more elegant way of doing this. Thus the question - how do you guys deal with modifying web.config that is under source control during the CI builds?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您可以查看 Web 部署项目 VS 插件。 Scott Guthrie 在这篇帖子。
You can take a look at the Web Deployment Projects VS add-in. Scott Guthrie does a great job explaining it in this post.
为什么不使用可以编辑 XML 的命令行实用程序来修改 web.config 作为构建步骤的一部分？
例如，获取一个命令行实用程序，其工作原理如下：
然后每个调试/发布（零售）都有不同的值。
Why not modify web.config as part of a build-step using a command line utility that can edit XML?
e.g. Obtain a command line utility that works like:
Then have different value per debug/release(retail)..
为什么不直接让 web.config 读/写而不从源代码管理中检查出来，在构建过程中进行所需的更改，然后丢弃它们？
AFAIK SVN 无论如何都可以读取/写入文件。
Why don't you just make the web.config read/write without checking it out from source control, make your changes you need during the build process and then discard them?
AFAIK SVN has the files read/write anyway.
我们有一个
这允许我们在其中放置特定于环境的注释和值。通常必须将其放入某些文档中，并且肯定会被忽略。
就像我说的，我们在每次构建时都将 Hudson 部署到我们的证书环境中，因此它只是复制目录，删除 web.config 并将 web.config.cert 重命名为 web.config
您可能想查看 Hudson，我不想我想我听说过有人选择 CC.net 而不是 Hudson，如果他们有能力选择:)
we have a
This allows us to put comments in there and values in there specific to the environments when that would normally have to go in some documentation somewhere, and it would surely be ignored.
Like I said, we have Hudson deploy to our cert environment on each build, so it just copies the directory over, deletes the web.config and renames web.config.cert to web.config
You may want to check out Hudson, I dont think I've ever heard of anyone choosing CC.net over Hudson if they had the ability to choose :)