所以，我今天通过检入配置文件杀死了构建。它知道服务器在哪里（想想SQL服务器等），而且我一直在反对在我的盒子上运行的服务器。通常，或者更确切地说，在其他情况下，我们会针对中央服务器运行。当然，每日构建没有找到“我的”服务器，因此破损。然后，在签入之前编辑配置文件以指向“普通”服务器，并在签入后再次编辑它。
我很想让VC忽略配置文件，这样就不会意外地检查它。另一方面，存储库应包含一个干净，可用的文件版本。我不可能忽略它并同时检查它，现在，我可以吗？
所以，我正在寻找的是一种方法，有一个文件，错误，检查，但永远不会检入。至少在最常见的情况下 - 如果配置文件发生重大变化，一些特殊的程序将新版本放入存储库是可行的。
如果您以前遇到过这个问题，我会对您找到的任何解决方案感兴趣。只要它们不破坏构建，那就是;）
答案 0 :(得分：12)
除非添加了一些新配置，否则您可以使用默认配置文件保持不变。然后你有一个不同的文件覆盖默认文件的配置。
config.Default.xml
config.User.xml
只有config.Default.xml是源代码控制的。 config.User.xml仅包含与您不同的配置。因此，假设您正在本地SQL服务器上进行测试，您只在其中放置连接字符串，它将覆盖config.Default连接字符串。
看一下.Net Framwork应用程序配置，它可以为您完成大部分（如果不是全部）工作。
答案 1 :(得分：3)
我使用的一种方法是拥有两个版本的配置文件，并让安装程序脚本提取正确的版本。
两个文件都包含相同的键，但其中一个包含'dev'值，另一个包含我们期望部署的值并在字段中进行编辑。
答案 2 :(得分：1)
我们将这些类型的文件存储在我们的源代码管理系统中，并为我们正在构建的环境提供不同的文件夹。
所以我们有：
Dev
Test
Live
其他环境特定文件下有子文件夹。
答案 3 :(得分：1)
我们有
Hudson删除初始文件并为正确的环境部署正确的文件（目前只有cert）。
这允许开发人员独立地记录和开发生产，证书和开发级配置文件，并在SVN中单独进行版本化。
答案 4 :(得分：1)
我认为接受的答案是好的，但根据您的要求，它可能有局限性。
我们使用以下方法。请注意，我们是使用VS的.NET商店，并使用MSBuild（内置，社区和自定义）任务。
项目的BeforeBuild任务查找 App.config 的存在，如果找不到，则将 App.default.config 复制到 App.config 。此外，构建服务器始终删除 App.config （如果它存在于CI构建中）（确保干净的配置）。然后，我们还使用MSBuild社区FileUpdate任务，根据构建项目的内容将标记替换为适当的值。
例如，一个新的开发人员签出可以为本地数据库设置数据库连接字符串，可以为夜间数据库设置每晚构建等。
答案 5 :(得分：0)
如果我工作，我们有单独的配置文件进行部署。因此，我们解决方案中的配置文件是开发版本，人们可以根据自己的内容进行更改。这些配置文件永远不会部署在任何地方。
部署的配置文件存储在源代码管理提供程序的单独位置。如果有人需要进行将要部署的配置更改，则必须修改此版本。
答案 6 :(得分：0)
接受的答案是好的。但是，如果您的版本控制系统具有更改列表的概念，则可以执行您想要的操作（4年前），并且只维护一个检出并且从不签入的配置文件。我在Perforce中做到了这一点：
查看配置文件并将其保存在自己的更改列表中。提交时，只提交其他更改列表;如果您将配置文件更改列表命名为“DO NOT COMMIT”，则很容易记住。
此系统的一个优点是，如果其他人更改配置文件的生产版本 - 即服务器上存在的版本，以及每个人都维护修改后的本地版本 - 那么您将收到通知从服务器获取配置文件时可能会发生冲突。使用类似于已接受答案中建议的解决方案，您可以使用本地设置静默覆盖新的生产设置，这可能会破坏您的本地构建或导致您在下次提交时中断构建。
答案 7 :(得分：-1)
对于每个配置文件x，创建一个名为x.dist的签入文件，这是默认的分布式配置。开发人员签出后，有一个脚本将每个x.dist文件复制到x，他们可以根据需要自定义x。可以重新运行此脚本以在主要更改后更新文件，或者开发人员可以手动合并其更改。
对于部署，您可以签入实时部署文件并让您的启动脚本明确引用它们（例如--config x.production）。
例如，这种方法用于如何分发Wordpress（您必须复制模板wp-config.php文件）或在使用autoconf的开发项目中（其中configure.ac已签入但是配置文件必须由每个开发人员生成;构建一个特殊的配置文件，以便在发布时在tarball中分发。