2

我们在所有 TeamCity 代理上都安装了 BullsEye Coverage，并且有一个夜间脚本可以打开 BullsEye，重建我的项目，运行单元测试，然后关闭 BullsEye。BullsEye bin 目录不在机器的路径中，我的脚本在运行之前添加了路径。（该路径仅作为该会话的脚本的一部分添加，并且不会为整个机器永久设置）。

最近我在 TeamCity 构建日志中注意到所有项目（常规项目，而不仅仅是配置为运行覆盖的项目）都使用 BullsEye 编译器。这是日志中的一个示例：

[11:29:38] [bsii_algorithms\build\vc10\bsii_algorithms.vcxproj] ClCompile (8s)
[11:29:38] [ClCompile] CL (3s)
[11:29:38] [CL] C:\Program Files (x86)\BullseyeCoverage\bin\CL.exe /c /I..\..\include /I..\..\..\bsii_common\include ...

此外，其中一个项目的构建速度非常慢。具体来说，“ResolveProjectReferences”大约需要 20 分钟。我在网上读到这可能发生，因为某种分析已打开。所以我使用 TeamCity 用户登录服务器并再次关闭 BullsEye。但这没有帮助。

所以我的问题是：

  • 即使 BullsEye 不在机器路径中，是否可以使用 BullsEye 文件夹中的编译器编译所有内容？
  • 如何配置机器以便只有覆盖脚本使用 BullsEye 编译器？
  • 这可能是构建需要很长时间的原因吗？

谢谢！

4

2 回答 2

2

请注意，靶心是全局打开的（通过注册表？），因此与您的覆盖构建并行运行的任何构建都会发现自己（部分）被检测。出于这个原因，我们在他们自己的机器上运行我们的覆盖构建。

于 2015-01-19T13:45:41.743 回答
0

是的，预计会使用 Bullseye 文件夹中的编译器。这就是 Bullseye 覆盖工具的工作方式，通过使用特殊的“检测版本”拦截实际编译器。最终，Visual Studio 编译器被称为底层。

如果您删除脚本启用 Bullseye 的步骤（通过调用“cov01 -1”），那么 Bullseye 编译器应该只传递到 Visual Studio 编译器，您将不会有代码覆盖。

我不确定时间问题。

链接到 VS Bullseye 文档：这里

于 2014-05-22T11:21:04.130 回答