为什么使用BullsEye编译器编译项目？

Question

我们在所有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编译器？
• 这可能是构建需要很长时间的原因吗？

谢谢！

Answer 1

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

如果你删除了脚本启用Bullseye的步骤（通过调用'cov01 -1'），那么Bullseye编译器应该只对Visual Studio编译器进行传递，你就不会有代码覆盖。

我不确定时间问题。

链接到VS Bullseye文档：here

Answer 2

请注意，bullseye是全局启动的（通过注册表？），因此任何与您的coverage构建并行运行的构建都会发现自己（部分）已经过检测。出于这个原因，我们在他们自己的机器上运行我们的覆盖范围。