git中的web.config和app.config特定于机器的设置

Question

我们在不同的办事处拥有多个开发团队，他们需要在项目的web.config和app.config文件中为大量配置设置提供不同的值。

我们希望使用一组合理的默认值来检查这些配置文件，这样通过检查trunk / master分支，您可以正常工作而无需挖掘配置文件。

从历史上看，我们使用过Subversion，特别是TortoiseSVN，这提供了一种管理本地更改的简便方法：我们只是将这些文件添加到TortoiseSVN的自动ignore-on-commit更改列表中。这可以防止意外签入这些文件，因为您需要专门选择它们以将其包含在签入中（并且您可以确保检查重大更改，而不是本地配置噪声）。这种方法的主要缺点是配置文件总是看起来“已经改变”，因此无法一目了然地知道您是否有任何本地更改。

我们希望转而使用Git，而我正试图找出最佳方法。

首先，其他StackOverflow答案中已有的内容：

选项1：签入xxx.sample文件并.gitignore实际配置文件：建议这样做，例如this answer。我看到的主要问题是在两个不同的点上容易忘记对配置文件的更改：提交者很容易错过他们需要添加到.sample文件和消费者的更改（特别是持续集成）服务器）很容易错过他们需要从.sample文件合并到他们的本地配置文件中的更改。所以基本上，这似乎不是一个很好的解决方案。

选项2：拥有一个已签入的xxx.defaults文件和一个.gitignored xxx.local配置文件，该文件会覆盖它定义的任何设置：这是提供的，例如，{{3} }。问题是我们正在使用标准的.Net配置提供程序 - 当Mirosoft已经完成所有工作时，我真的不希望我们实现一个全新的设置加载框架。有没有人知道如何获取app.config和web.config文件以引用可选的本地覆盖文件？

选项3：让开发人员保留本地分支机构，然后让他们总是检查樱桃选择或重新分支到主服务器，以便始终绕过/避免本地分支中不需要的提交：这是作为可能的工作流here提供，虽然我在变更跟踪（所有签入的内容）方面都非常感谢它的清晰度，但它在每次单独检查时都会引入大量所需的开销;这是一个很大的痛苦！

选项4：签入配置文件，但将其标记为--assume-unchanged ：这是一个可能的选项here;据我所知，它与TortoiseSVN中的ignore-on-commit更改列表在精神上非常相似，除非您在提交过程中无法看到这些“隐藏”更改的文件;例如，TortoiseGit会显示带有“已更改”图标覆盖的文件，但在提交对话框中，文件根本不会显示。这似乎有点可怕，再次很容易忘记检查更改。

鉴于这些选项，我发现的所有选项，我真的希望有一种方法可以选择“包含”本地配置文件到/登录的app.config / web.config文件中选择选项2 ;有没有人知道这样做的方法，或者我缺少的其他选择？ （我很想尝试一个自定义的Xml合并预构建步骤......）

我之前应该提到过，我们仍然使用VS2008，因此无法使用配置转换。

---

更新：（已删除，明显错误）

更新2：我删除了之前的更新和回答，这是愚蠢的/不起作用。我没有意识到在“我们的”合并之后，另一个方向的下一次合并会带回这些文件的“原始”版本（覆盖本地分支的变化）;如果您有兴趣，请参阅编辑历史记录。这个问题一如既往地开放。

Answer 1

我建议你看一下ConfigGen。我们在所有项目中都使用它，它为所有开发人员以及我们所有的环境创造了奇迹。它基本上运行一个表示机器名称和输出配置文件的电子表格，然后标记模板App.Config或Web.Config，将电子表格中的值替换为它。为项目添加一个简单的预构建步骤以运行configgen，在构建开始之前，您有一个为您的计算机定制的配置文件。它还支持默认设置。

看看网站并自己动手，但我绝对可以保证。

编辑：值得注意的是，您可以忽略所有的Web.config和App.config文件（就.git而言）。但您确实需要将模板和电子表格添加到仓库中。此外，我确信有一个更新的方式可能包括xml替换电子表格，它有自己的编辑器，使其显然更适合DVCS。

Edit2 ：另请查看Daniel的帖子：https://stackoverflow.com/a/8082937/186184。他给出了一个非常明确的模板和电子表格示例，以及如何在解决方案中使用它。

Answer 2

你考虑过content filter driver吗？

这意味着，在每个git checkout上，涂抹脚本将生成基于以下内容的实际配置文件：

• 配置模板文件（配置值占位符，如@@A_PARAM_VALUE@@）
• 其中一个配置值文件（每个开发人员可以保留他/她自己的配置文件值的版本）

避免任何合并问题和gitignore设置：每个“配置值文件”都不同并保持独立 这也与ConfigGen的pms1969中提到的answer等其他配置生成解决方案兼容。

Answer 3

我会this answer for Managing complex Web.Config files between deployment environments查看Dan的潜在解决方案。我使用mercurial并使用相同的过程来检入通用的web.config文件并使用Web转换来更改configSource的位置以指向我的部署特定内容。

使用此路由的优点是它完全内置于框架中，不需要额外的代码，并且可以与Web部署配合使用。

在web.config中检查：

<?xml version="1.0"?>
<configuration>
  <!-- snip -->
  <connectionStrings configSource="config/connectionStrings.config" />
</configuration>

在web.debug.config中检查：

<?xml version="1.0"?>
<configuration>
  <connectionStrings
      configSource="config/dev.connectionStrings.config"
      xdt:Transform="Replace(configSource)" />
</configuration>

我已使用默认值签入config/connectionStrings.config，但未检入开发服务器config/dev.connectionStrings.config，并且未在新部署中替换它。

Answer 4

我们在公司遇到了类似的困境。我们最终创建了独立的配置分支，补充了主分支。例如 - develop-config，master-config等。然后我们有一个小脚本，它将根据部署环境使用正确的源分支重新定义这些分支。因此，例如在开发机器上，我们将使用develop来修改develop-config。如果您正在使用本地计算机，您将获得默认配置（由所有开发人员同意），该配置已签入主分支（如本地数据库名称，密码等）。当然，缺点是你必须始终保持这些* -config分支最新，或者在部署时让它们加速。

自从实现这个工作流程以来，我遇到了一些像whiskey_disk这样的部署工具，这些工具采用了类似的方法。事实上，我更喜欢他们的解决方案，因为它更加安全和灵活。虽然它可能不适合你们，因为它更倾向于LAMP / RoR开发堆栈。

除此之外，还有一些商业解决方案，您可能需要查看Beanstalk

Answer 5

自2012年以来有点变化，现在我建议您构建/部署工具（VS Team Services，TeamCity，Octopus Deploy）管理特定于环境的配置。

如果您使用azure，则可以将应用设置和连接字符串定义为应用定义的一部分。