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

web.config and app.config machine-specific settings in git

提问by Tao

We have multiple teams of developers in different offices, and they need different values for a number of configuration setting in our projects' web.configand app.configfiles.

我们在不同的办公室有多个开发团队，他们需要为我们项目web.config和app.config文件中的许多配置设置不同的值。

We like to keep these configuration files checked in with a sensible set of default values, so that by checking out the trunk/master branch you have something working without needing to dig around for configuration files.

我们喜欢使用一组合理的默认值检查这些配置文件，这样通过检查主干/主分支，您就可以在不需要挖掘配置文件的情况下工作。

Historically we've used Subversion, and specifically TortoiseSVN, and this provided an easy way to manage local changes: We simply added these files to TortoiseSVN's automatic ignore-on-commitchangelist. This prevents accidental checkin of these files, as you then need to select them specifically to include them on a checkin (and you can make sure you're checking in significant changes, not local-config noise). The main disadvantage of this approach is that the config files always look "changed", so it's not possible to at-a-glance know whether you have any local changes.

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

We're looking to switch to Git, and I'm trying to figure out the best approach.

我们正在寻求切换到 Git，我正在尝试找出最佳方法。

First off, what's already there in other StackOverflow answers:

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

Option 1: Check in xxx.sample files and .gitignore the actual config files: This is recommended, for example, in this answer. The main problem I see with this is that changes to the config file are easily forgotten, at two different points: The committer can easily miss changes that they need to add to the .samplefile, and consumers (esp. continuous integration server) can easily miss changes that they need to incorporate from the .samplefile into their local config file. So basically, that doesn't seem like a very good solution.

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

Option 2: Have a checked-in xxx.defaults file and a .gitignored xxx.local config file which overrides any settings it defines: This is offered up, fr example, here. The issue there is that we're working with standard .Net configuration providers - I really don't want us to implement a whole new settings-loading framework when Mirosoft's already done all the work. Does anyone know a way to get app.config and web.config files to refer to optional local override files?

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

Option 3: Have developers keep local branches, and then have them always check in cherry-picks or rebased branches into master, to always bypass/avoid the unwanted commits in their local branch: This is offered as a possible workflow here, and while I appreciate the cleanliness of it in terms of change-tracking (everything checked in), it introduces a significant amount of requiredoverhead on every single checkin; it's a major pain!

方案3：有开发商保持局部分支，然后让他们经常检查以樱桃木选秀权或重订分支成高手，总是旁路/避免在当地的分公司不需要提交：这是献作为一个可能的工作流程在这里，而我欣赏它在更改跟踪（所有签入）方面的清洁度，它在每次签入时引入了大量所需的开销；这是一个很大的痛苦！

Option 4: Have config files checked in, but have them marked with --assume-unchanged: This is offered as a possible option here; as far as I can tell it's very similar in spirit to the ignore-on-commitchangelist in TortoiseSVN, except you have no visibility to these "hidden" changed files in a commit process; TortoiseGit, for example, does show the file with a "changed" icon overlay, but in the commit dialog the file does not show up at all. This seems a little frightening, again very easy to forget to check changes in.

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

Given these options, which are all the ones I've found, I'm really hoping for a way to optionally "include" a local config file into/over a checked-in app.config/web.config file and go with option 2; does anyone know of a way to do this, or other options that I'm missing? (I'm faintly tempted to consider a custom Xml-merging pre-build step...)

鉴于这些选项，这是我找到的所有选项，我真的希望有一种方法可以选择将本地配置文件“包含”到/超过签入的 app.config/web.config 文件并使用选项2; 有没有人知道这样做的方法，或者我缺少的其他选项？（我有点想考虑自定义 Xml 合并预构建步骤......）

I should have mentioned earlier, we're still on VS2008, so Configuration Transforms are not available.

我应该早先提到，我们仍然在 VS2008 上，所以配置转换不可用。

---

---

UPDATE:(deleted, was plain wrong)

更新：（已删除，完全错误）

UPDATE 2:I've deleted my previous update and answer, it was stupid / didn't work. I didn't realize that after an "ours" merge, the next merge in the other direction carries the "original" versions of those files back (overwrites the local branch changes); see edit history if you're interested. This question is as open as ever.

更新 2：我已经删除了我之前的更新和答案，这很愚蠢/没有用。我没有意识到在“我们的”合并之后，另一个方向的下一次合并将这些文件的“原始”版本带回（覆盖本地分支更改）；如果您有兴趣，请查看编辑历史记录。这个问题一如既往地开放。

回答by pms1969

I'd like to suggest you look at ConfigGen. We use it in all our projects, and it works wonders for all the developers and also for all our environments. It basically runs off a spreadsheet that states machine name and output configuration file, and then tokenises a template App.Config or Web.Config, substituting values from the spreadsheet into it. Add a simple pre-build step to your projects to run configgen, and before the build kicks off, you have a tailored configuration file for your machine. It also supports default settings.

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

Take a look at the site and make your own mind up, but I can definitely vouch for it.

看一看该网站并做出自己的决定，但我绝对可以保证。

EDIT: It's worth noting that you can then ignore all your Web.config and App.config files (in terms of .git). But you do need to add your templates and spreadsheets to the repo. Also, I am assured there is an update on the way that may well include an xml replacement for the spreadsheets, that has it's own editor, making it eminently more suitable for DVCS's.

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

Edit2: Also take a look at Daniel's post here: https://stackoverflow.com/a/8082937/186184. He gives a very clear example of the template and spreadsheet, and how to get it working in your solution.

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

回答by VonC

Did you consider a content filter driver?

您是否考虑过内容过滤器驱动程序？

That would mean, on each git checkout, the smudge script would generatethe actual config file based on:

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

• a config template file (with config value placeholder like @@A_PARAM_VALUE@@)
• one of the config value file (each developer can keep versioned his/her own config file values)

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

That avoid any merge issue and gitignore settings: each "config value files" are different and remain separate.
This is also compatible with other config generation solution like ConfigGenmentioned in pms1969's answer.

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

回答by Joshua

I would take a look at this answer for Managing complex Web.Config files between deployment environmentsby Danfor a potential solution. I use mercurial and use this same process to have a generic web.config file checked in and use the web transforms to change the location of configSourceto point to my deployment specific stuff.

我想看看这个答案管理部署环境之间的复杂的Web.config文件由丹一个潜在的解决方案。我使用 mercurial 并使用相同的过程来签入一个通用的 web.config 文件，并使用 web 转换来更改configSource指向我的部署特定内容的位置。

The advantage of using this route is it is completely built in to the framework, requires no extra code, and works with web deployment.

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

Checked in web.config:

在 web.config 中检查：

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

Checked in web.debug.config:

在 web.debug.config 中检查：

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

I have a config/connectionStrings.configchecked in with defaults, but the development servers config/dev.connectionStrings.configis not checked in and its not replaced on a new deployment.

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

回答by jesal

We ran into a similar dilemma at our company. We ended up creating separate configuration branches which supplement the main branch. Like for example - develop-config, master-config, etc. We then have a small script which will rebase those branches with the correct source branch based on the deployment environment. So for example on the development machine we would rebase develop-config with develop. If you are working on local machine, you would get the default configuration (agreed upon by all developers) which is checked into the main branch (like the local DB name, password, etc). Of course the downside is that you always have to keep those *-config branches up-to-date or get them upto speed at the time of deployment.

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

Since implementing this workflow, I've come across couple of deployment tools out there like whiskey_diskwhich take a somewhat similar approach. In fact I like their solution a lot more since its much more secure and flexible. Although probably not a good fit for you guys since its geared more towards a LAMP/RoR development stack.

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

Aside from that, there are also some commercial solutions out there that you might want to take a look at like Beanstalk

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

回答by tymtam

A bit has changed since 2012 and these days and now I would suggest your build/deploy tool (VS Team Services, TeamCity, Octopus Deploy) managing environment specific configurations.

自 2012 年和现在以来发生了一些变化，现在我建议您使用构建/部署工具（VS Team Services、TeamCity、Octopus Deploy）来管理特定于环境的配置。

If you work in azure you can define app settings and connection strings as part of your app definition.

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