我在TFS中有一个很大的代码库，它有多个.sln文件，每个文件包含许多项目和至少一个单元测试项目。大多数单元测试依赖于常见的XML和XSD文件，并且在单元测试时代码还需要几种其他类型的文件（.config，.xaml等）。
由于TFS构建和收集单元测试文件的方式，TestResults文件夹中缺少大部分文件，因此在我们的CI构建期间测试失败[这已经发生了一段时间，但我'我是项目的新手，我正在努力修复错误]。 TFS似乎要做的是：首先，它将所有代码检出到src文件夹（使用Solution1，Solution2等）并构建它，就像开发人员在本地执行一样。其次，它将构建输出复制到bin \ Binaries文件夹。第三，它查找所有 test .dll文件，复制它们及其依赖项（但仅限于依赖项），再将App.config文件复制到TestResults \ Deploy_ [date / time] \ Out文件夹，并在那里进行单元测试。
我遇到了两个问题。因为第二步是将所有构建输出组合到一个文件夹中，所有具有重复名称的文件将相互覆盖。因此，只有一个App.config文件，即使每个解决方案都有自己的。这也发生在其他config / xml文件中，并且有两个命名不佳的单元测试.dll。如果必须的话，我可以忍受这个，因为大多数配置文件都是重复的，其他文件可以重命名。
第二个问题是大多数额外文件没有进入TestResults文件夹，当它们不存在时，单元测试将失败。我知道使用[DeploymentItem]属性;如果这是唯一的解决方案，我会走那条路，但是有太多额外的文件，我正在寻找不同的方法。
所以我的问题是，如何配置我的tfs-run builds＆amp;单元测试包括他们需要的所有文件，没有所有的工作和添加大量[DeploymentItem]属性的维护问题，也不会影响本地构建和为开发人员进行单元测试？
我发现有一件事是将[DeploymentItem]属性添加到单元测试实际上会导致使用部署文件夹。没有它，它会在二进制文件夹中运行单元测试。请参阅“何时使用单独的部署文件夹？”下的http://msdn.microsoft.com/en-us/library/ms182475.aspx
同样在该页面上，它表示您可以指定要在.testsettings文件中部署的文件，但随后表示您应该避免使用它，因为您的测试运行速度会变慢。较新的替代文件.runsettings文件不允许您列出要部署的文件。
如果启用了代码覆盖，我们目前不会进行部署覆盖，但计划在测试通过后，也会启用部署。
答案 0 :(得分：1)
在TFS 2013中，您可以执行powershell预测试，以便以您需要的方式组织文件。您可以使用2013年前的测试设置文件来获取部署测试的文件。
但是，如果测试设置文件不够，您可以使用社区构建工具直接在之前的版本中调用powershell到2013年。
如果你被困在2012年，那么你将需要使用.testsettings文件来推送你需要的位。是的，它会使你的构建变慢，但除了如上所述定制构建过程之外，这是你唯一的选择。