假设我们有一个典型的Web应用程序，并且具有文件配置。每个从事该项目的开发人员都将为其开发箱提供一个版本，并将提供一个开发，生产和阶段版本。我们如何在源代码管理中处理此问题？根本不检查该文件，使用其他名称检查它还是一起做一些花哨的事情？

解决方案

回答

不要对该文件进行版本控制。版本化模板或者其他内容。

回答

当前，我具有添加了扩展名的"模板"配置文件，例如：

web.config.rename

但是，如果关键更改已更改，我会发现此方法存在问题。

回答

@格兰特是正确的。

我与其他将近100个开发人员组成一个团队，并且我们的配置文件未检入源代码管理。我们在存储库中有文件的版本，每次签出时都会将它们拉出，但它们不会更改。

对我们来说效果很好。

回答

我过去所做的是拥有一个默认配置文件，该文件已签入到源代码管理中。然后，每个开发人员都有自己的替代配置文件，该文件被从源代码管理中排除。该应用程序首先加载默认值，然后如果存在覆盖文件，则将其加载并使用从覆盖优先级到默认文件的任何设置。

通常，替代文件越小越好，但是对于具有非常非标准环境的开发人员来说，替代文件始终可以包含更多设置。

回答

我对它进行版本控制，但从不将其推送到其他服务器。如果生产服务器需要更改，我直接将更改更改为配置文件。

它可能不漂亮，但效果很好。

回答

签入的普通版本的app / web.config应该足够通用，以在所有开发人员机器上都可以使用，并应保持最新状态，以进行任何新的设置更改等。如果我们需要开发人员的一组特定设置/ test / production设置，如GateKiller所述，以某种命名约定检入带有这些设置的单独文件，尽管我通常使用" web.prod.config"，以便不更改文件扩展名。

回答

我们使用已检入版本控制的模板配置文件，然后使用自动构建中的步骤将模板文件中的特定条目替换为特定于环境的设置。特定于环境的设置存储在单独的XML文件中，该文件也受版本控制。

我们在自动构建中使用MSBuild，因此我们使用MSBuild社区任务中的XmlUpdate任务来更新值。

回答

我的团队为每个环境(web.config.dev，web.config.test，web.config.prod)保留不同版本的配置文件。我们的部署脚本复制出正确的版本，并将其重命名为web.config。这样，我们对每种环境的配置文件都有完整的版本控制，可以轻松执行diff等。

回答

很长时间以来，我所做的正是bcwood所做的。我将web.dev.config，web.test.config，web.prod.config等的副本保留在源代码控制下，然后当我的构建/部署系统部署到各种环境时，它们会自动重命名它们。我们在文件之间会获得一定程度的冗余(尤其是其中包含所有的asp.net东西)，但是通常它确实运行良好。我们还必须确保团队中的每个人都记得在进行更改时更新所有文件。

顺便说一句，我喜欢将" .config"作为扩展名保留在末尾，以免文件关联被破坏。

至于配置文件的本地开发人员版本，我总是尽力鼓励人们尽可能使用相同的本地设置，从而无需拥有自己的版本。它并不总是对每个人都有效，在这种情况下，人们通常只是根据需要在本地替换它并从那里去。这不是太痛苦或者什么。

回答

我们只是保持生产配置文件处于签入状态。开发人员有责任在安全地将其从源中拉出来进行登台或者开发时更改文件。过去这已经烧死了我们，所以我不建议这样做。

回答

+1模板方法。

但是由于这个问题带有标签Git，因此分布式替代方案
想到，在私人测试中保留自定义项
分支：

A---B---C---D---           <- mainline (public)
     \       \
      B'------D'---        <- testing (private)

在此方案中，主线包含通用的"模板"配置
文件，只需进行最少的调整即可使用。

现在，开发人员/测试人员可以将配置文件调整到他们的心脏。
内容，并且仅在本地将这些更改私人提交
测试分支(例如B'= B +定制)。每次主线
进步，他们毫不费力地将其合并到测试中，从而
合并提交，例如D'(= D + B的自定义项的合并版本)。

当"模板"配置文件更新时，该方案确实很出色：
双方的变更被合并，并且极有可能
如果不兼容，将导致冲突(或者测试失败)！

回答

在我们的项目中，我们将配置存储在带有前缀的文件中，然后我们的构建系统根据当前系统的主机名提取适当的配置。这对于一个相对较小的团队来说非常有效，如果/当我们添加新的配置项时，允许我们将配置更改应用于其他人的文件。显然，这绝对不能扩展到拥有无数开发人员的开源项目。

回答

我以前使用过模板，即web.dev.config，web.prod.config等，但现在更喜欢"覆盖文件"技术。 web.config文件包含大多数设置，但是外部文件包含特定于环境的值，例如db连接。保罗·威尔逊(Paul Wilson)博客上的精彩解释。

我认为这减少了配置文件之间重复的数量，这在添加新值/属性时可能会引起麻烦。

回答

配置是代码，我们应该对其进行版本控制。我们的配置文件基于用户名；在UNIX / Mac和Windows中，我们都可以访问用户的登录名，只要这些登录名对项目来说是唯一的，就可以了。我们甚至可以在环境中覆盖它，但是我们应该对所有内容进行版本控制。

这也使我们可以检查其他人的配置，这可以帮助诊断构建和平台问题。

回答

我们使用的解决方案是只有一个配置文件(web.config / app.config)，但是我们在文件中添加了一个特殊部分，其中包含所有环境的设置。

有一个LOCAL，DEV，QA，PRODUCTION部分，每个部分都在我们的配置文件中包含与该环境相关的配置密钥。

使这一切正常进行的原因是一个名为xxx.Environment的程序集，该程序集在我们所有应用程序(winforms和webforms)中都被引用，该程序告诉应用程序正在其上运行的环境。

xxx.Environment程序集从给定机器的machine.config中读取一行信息，告诉它它位于DEV，QA等上。我们所有的工作站和服务器上都存在此条目。

希望这可以帮助。

回答

这里有两个问题。

• 首先，我们必须控制软件随附的配置文件。如果开发人员在迁移环境中使用相同的文件，则开发人员很容易签入不需要的文件以更改主配置文件。另一方面，如果安装程序包含一个单独的配置文件，则很容易忘记为它添加新设置，或者让其中的注释与扩展中的注释不同步。配置文件。
• 然后，我们面临的问题是，当其他开发人员添加新的配置设置时，开发人员必须将配置文件的副本保持在那里。但是，每个开发人员的某些设置(如数据库连接字符串)都不同。
• 问题/答案未涵盖的第三个问题。在安装新版本的软件时，如何合并客户对配置文件所做的更改？

I have yet to see a good solutions
  that works well in all cases, however
  I have seen some partial solutions
  (that can be combined in different
  combinations as needed) that reduces
  the problem a lot.

• 首先，减少主配置文件中的配置项数量。如果不需要让客户更改映射，请使用Fluent NHibernate(或者其他方式)将配置移入代码。视情况注入设置也是如此。
• 尽可能拆分配置文件，例如使用一个单独的文件来配置Log4Net记录的内容。
• 不要在许多配置文件之间重复项目，例如如果我们有4个Web应用程序都安装在同一台计算机上，则应具有一个整体配置文件，每个应用程序中的web.config文件都指向该文件。 (默认情况下使用相对路径，因此很少需要更改web.config文件)
• 处理开发配置文件以获取运输配置文件。可以通过在Xml注释中具有默认值来完成，然后在完成构建时在配置文件中设置默认值。或者在创建安装程序的过程中删除部分。
• 每个开发人员要拥有一个数据库连接字符串，而不仅仅是拥有一个数据库连接字符串。例如，在运行时首先在配置文件中查找database_ianr(其中ianr是我的用户名或者计算机名)，如果找不到，则查找数据库具有第二级"例如-oracle或者-sqlserver"，使开发人员可以更快进入两个数据库系统。对于其他任何配置值，当然也可以这样做。然后，可以删除所有以_userName结尾的值，然后再发送配置文件。

However in the end what is you is a
  “owner of configuration file” that
  takes the responsibly of managing the
  configuration file(s) as above or
  otherwise.   He/She should also do a
  diff on the customer facings
  configuration file before each
  shipment.

缺少这些问题，我们无法消除对有爱心人士的需要。