gpt4 book ai didi

version-control - 使用版本控制时处理多台机器上的 web.config 差异

转载 作者:行者123 更新时间:2023-12-04 06:55:31 26 4
gpt4 key购买 nike

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

最常见的是:

  • Web 服务器 (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 的构建脚本?

    提前致谢,
    斯蒂芬。

    编辑

    看起来下一个 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 在拥有一个更友好的版本方面真的会有所帮助。

    最佳答案

    我有时使用的一种方法是将特定于环境的部分分解为单独的配置文件,这些文件通常被排除在部署之外(第一次或它们的结构发生变化时除外):

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

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

    connection.config 文件(通常不包含在部署中;因此它保持不变):
    <?xml version="1.0"?>
    <connectionStrings>
    <add name="connectionName" connectionString="[connection string goes here]"/>
    </connectionStrings>

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

    关于version-control - 使用版本控制时处理多台机器上的 web.config 差异,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1017240/

    26 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com