views:

75

answers:

1

I'm building VS2010 solutions on a TFS2008 build agent with VS2010 Ultimate installed; code compiles fine, and the tests all run fine, but when it comes to code coverage, nothing is being reported. I've checked that the .testsettings file has Code Coverage enabled and that I have selected some assemblies to instrument, and if I run the tests locally on my developer PC, code coverage is analysed and reported successfully.

However when built on the build server, code coverage is not reported. I can see a data.coverage file sitting in the build's TestResults\guid\In\MachineName folder, so it's obviously done something, but the build logs contain no mention of anything to do with code coverage, and no warnings/errors.

Update: checking on the TFS server itself, the application log contains the following error:

The Code Coverage Analysis Service could not analyze the code coverage data for build Daily Build>20100812.2 (Any CPU/DEBUG). This is frequently caused by publishing different versions of the same binary to a particular build. Processing of code coverage data from run svcTFSService@W2411193 2010-08-12 12:52:34_Any CPU_Debug caused the following exception to be thrown: Error when creating coverage info: Error loading symbol file. Symbol and binary files should be in the same folder as the coverage file or on the symbol path: D:\Source\CommonPlatform\Common Platform Development Daily Build\Binaries\Debug\Core.dll.

Yet when I look on the build agent in the specified folder, both the assembly and its debug symbol file are in the expected location.

Update 2: On a whim, I tried opening the data.coverage file that I mentioned above in VS 2010 on the build agent, and I get the following error:

Code Coverage Analysis engine threw exception(s): Image file "D:\Source\CommonPlatform\Common Platform Development Daily Build\Binaries\Debug\Core.dll" could not be found.

Yet I can plainly see the file sitting in the filesystem, as well as its PDB.

A: 

Check to see if the file timestamps are essentially the same on both the symbol file and the assembly. They shouldn't be off by more than a second (or two at the most). If they are, it might be that you are building Core.dll in more than one place, and only one is creating the symbol file.

It might be a long shot, but it's probably a good place to start.

Robaticus
Timestamps match to the second :-(
David Keaveny
hmmm. I guess it was a longshot. Sorry.
Robaticus