I recently had an opportunity to play around with TeamCity and dotCover in while trying to measure test coverage. Basic idea is explained well in blog posting, but I found couple gotchas (reading manual is what I do as a last resort, as usual).
First was that analysed dll-files need to be from a debug build. pdb-files alone probably might do the trick, but easiest way to get those from all of our projects was to make a debug build. This of course can lead to funny situations, if your build has been configured to output files to same directory, regardless them being release or debug configuration. So this needs to be taken into account when collecting files automatically and packaging them for release (we don’t want to ship pdb-files along the release dlls)
Another gotcha is when you have configured different output directories (bin/debug and bin/release). If your build includes testing task that matches by wildcards (*test*.dll for example), changes are that you end up with debug and release binaries in unit testing. That is fast way of doubling your reported test cases though.
Third one is that when you finally get everything up and running, you need to know how to read the results. It seems that total coverage reported is only for those dll-files that actually got picked up while testing (well, that actually makes sense if you think about it). Those dll-files that were not used by the tests, are not reported and are not included in the total statistics.