【问题标题】:Visual studio 2010 - Per Developer/machine/environment Web.Config settingsVisual Studio 2010 - 每个开发人员/机器/环境 Web.Config 设置
【发布时间】:2011-08-22 15:48:24
【问题描述】:

想在这里挑选那些 MS Build/VS Post 构建指数的大脑。

我希望根据用户/机器/环境自定义我的 web.config 条目。

我可以在 web.config 中标记我的可配置/可更改条目,并希望这些条目被相应的用户/环境文件覆盖,并希望有一个顺序来决定如果找到条目应该优先于另一个条目在多个文件中。

例如:web.config 有一个 $connectionstring 条目,每个用户/环境的自定义文件可能具有替换 $connectionstring 的潜在值,具体取决于构建解决方案的上下文/配置

这意味着,我可以有一组如下文件:

user_joe.config

       $connectionstring = db_where_joe_like_to_connect_to 

staging.config

       $connectionstring = db_where_staging_connect_to  

生产.config

       $connectionstring = db_production

因此,如果 joe 从他的开发框中编译解决方案,则 web.config 的 $connectionstring 应该具有值“db_where_joe_like_to_connect_to”。

我希望有一个不涉及 Nant 的解决方案。

希望有人能指点一下。

【问题讨论】:

    标签: visual-studio-2010 msbuild post-build-event


    【解决方案1】:

    您可以使用 Visual Studio 2010 的 web.config 转换设置。

    http://weblogs.asp.net/gunnarpeipman/archive/2009/06/16/visual-studio-2010-web-config-transforms.aspx

    这将允许每个开发人员拥有可以合并到其构建设置中的 web.config 部分。

    在内部,我们使用从网络上不同地方拼凑而成的事件——因为这通常发生在发布期间,我们希望它发生在编译时。

    添加一个 BeforeBuild 目标 所以 - 从 csproj 文件中:

    目标> xcopy "$(SolutionDir)Web.$(Configuration).config.transformed" "$(SolutionDir)Web.config" /R /Y属性组>

    【讨论】:

    • 这是一个糟糕的建议。所以你是说如果你有 20 个开发人员,你应该创建 20 个不同的构建目标 x 构建类型的数量?这是维护的噩梦。
    • 哎哟。糟糕的建议或困难的功能?如果您有更好的方法,我们愿意接受更好的建议,否则我会考虑改写为“那很不幸”。如果您希望在发布期间发生这种情况,那么这很容易。不幸的是,只是为了构建而发生了额外的步骤。
    • 神秘 - 还假设您阅读了下面的 cmets re multiple devs?
    • @AdamTuliper - 我在下面有一个更好的解决方案,它缺少“不幸”方面。
    • 如果我错了,请纠正我,但这不会覆盖主 Web.config 文件吗?那么未来的任何转换都将基于新转换的 Web.config 吗?会不会搞得一团糟?
    【解决方案2】:

    正如亚当在他的回答中所说,您可以使用 web.config 转换来做到这一点。基本上,您必须为每个环境创建一个新的解决方案配置。请注意,为每个开发人员配备一个可能很快就会变得无法维护,因为每个配置/平台组合都可以有自己的构建设置。

    此外,转换仅在网站打包期间应用(调用 Package 目标)。因此,如果您尝试使用此功能让 joe 和 sally 可以在他们自己的机器上拥有不同的配置,那么您不会这样做。

    在这种情况下,您最好尝试让每个人都使用相同的配置,而不是让配置碎片化。每个环境之间的差异越大,部署的难度就越大。

    【讨论】:

    • 同意,个性化配置可能会造成维护混乱,但我们的团队很小,我希望他们也知道自己在做什么:)
    • 好的,还请记住,您是开发人员必须为转换打包项目,然后安装它。因此,这些转换无助于日常开发。
    【解决方案3】:

    我建议在 web.config 条目中使用 configSource 属性进行调试构建。然后,在您的测试和发布版本中,您可以使用数据转换来插入测试和生产条目。

    你会这样做:

    <connectionStrings configSource="myLocalConnectionStrings.cfg" />
    

    然后您有一个名为 myLocalConnectionStrings 的本地文件,您没有将其签入源代码管理。在您的 Web.config.Release 中,您只需转换 connectionStrings 部分以包含生产字符串并删除 configSource 属性。

    【讨论】:

    • 我喜欢这样连接字符串,但是当您在没有自定义配置提供程序的情况下处理其他设置(应用程序设置、日志配置等)时,除了转换或...之外还有其他选择吗?跨度>
    • @AdamTuliper - 它适用于 web.config 中的任何内容。我认为它只适用于部分,而不是单个条目。因此,您必须在本地版本中包含所有条目。仅供参考,您可以在该部分中包含内部内容,但它将被忽略。这为您提供了一个很好的模板来创建您的自定义文件。
    【解决方案4】:

    这是一个 T4 解决方案。这适用于我的情况,因为这是一个仅供开发人员使用的内部工具,而且我不需要对“包含”文件进行进一步处理。

    文件名 App.tt.

    <#@ template debug="false" hostspecific="true" language="C#" #>
    <#@ import namespace="System" #>
    <#@ import namespace="System.IO" #>
    <#@ output extension=".config" #>
    <#
    string pathToConfigurations = Host.ResolvePath("Configurations");
    string pathToMachine = Path.Combine(pathToConfigurations, Environment.MachineName + ".config");
    if (File.Exists(pathToMachine))
    {
        Write(File.ReadAllText(pathToMachine)); 
    }
    else
    {
        Write(File.ReadAllText(Path.Combine(pathToConfigurations, "App.config")));  
    }
    #>
    

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2012-01-01
      • 1970-01-01
      • 2015-11-30
      • 2011-05-31
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多