We have BullsEye Coverage installed on all the TeamCity agents and there's a nightly script which turns on BullsEye, rebuilds my project, runs unit tests and then turns BullsEye off. The BullsEye bin directory is not in the path of the machines and my script adds the path prior to running. (The path is added only as part of the script for that session only and is not set permanently for the entire machine).
Lately I have noticed in the TeamCity build log that all projects (the regular ones, not just the ones which are configured to run coverage) use the BullsEye compiler. Here's an example from the log:
[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 ...
Also, one of the projects builds really slow. Specifically, "ResolveProjectReferences" takes about 20 minutes. I read online that this could happen because some sort of analysis is turned on. So I logged in to the server using the TeamCity user and turned BullsEye off again. But it didn't help.
So my questions are:
Thanks!
Yes, it's expected that the compiler from the Bullseye folder is used. This is how the Bullseye coverage tool works, by intercepting the actual compiler with a special "instrumented version". Eventually, the Visual Studio compiler is called under-the-hood.
If you remove the step where the scripts enable Bullseye (by calling 'cov01 -1'), then the Bullseye compiler should just do a pass-through to the Visual Studio compiler and you won't have code coverage.
I'm not sure about the timing question.
Link to the VS Bullseye documentation : here