4

After getting OpenCover to work on my machine, the next step is getting it to work with the build server.

I've been trying to integrate OpenCover with MSBuild on a Bamboo Build Server. I have modified Build.proj as follows to run OpenCover after building the solution:

<Target Name="TestAndCodeCoverage" DependsOnTargets="Build" >
    <Message Text="Executing Unit Tests and running OpenCover to check code coverage..." />
    <MakeDir Directories="Coverage" />
    <Exec Command='"C:\Program Files (x86)\OpenCover\OpenCover.Console.exe" -target:"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\MSTest.exe" -targetargs:/testcontainer:"TestProject\bin\Release\TestProject.dll" -filter:+[*]* -output:Coverage\CodeCoverageResults.xml -register:user -mergebyhash' />
</Target>

The "Coverage" directory is created in the solution root directory (which is the working directory during the build). The tests are run and all pass, but after Committing.... is displayed in the Build log (what would be displayed in the command line), no results are generated and the Build moves on to the next task (creating a report with ReportGenerator - this fails as CodeCoverageResults.xml was not created).

When running the same command in the command line on the build machine everything works as expected, and a report can be generated by ReportGenerator.

Has anyone else had the same problem? Do I need to register equivalent dlls like in this PartCover example?

Jack
  • 2,153
  • 5
  • 28
  • 43

1 Answers1

5

As the build server is a service then I would use the -register switch only, however if on a build server I would always say you should register both the 32 and 64 bit profilers, once, using regsvr32 and then drop the -register switch i.e. There is no need to register and unregister the profiler each time.

The -register[:user] switch is for those scenarios where people (like myself) like to work under limited permissions.

Shaun Wilde
  • 8,228
  • 4
  • 36
  • 56
  • It sound like you're about to fix my problem but I could do with some explanation as to what the -register flag does for me and why I need it for this to work. Cheers – Greg B Aug 18 '11 at 22:25
  • 1
    The profilers are COM objects and as such they need to be registered (in the Registry no less). Now you can let the host (Console) do this by using the -register switch (or -register:user if under a non-admin account or subject to UAC limitations) or you can use the regsvr32 utility; on build machines I prefer the latter if I have installed the profiler and I'd only use the -register switch if I had multiple builds that were being profiled by different versions of the profiler. HTH – Shaun Wilde Aug 18 '11 at 22:40
  • Any idea why I'm receiving no results although the profiler is registered and loaded correctly according to windows log? This happens only when running within bamboo (set up to run within Tomcat 6 under Local System Account), an test run in the same build directory using command line successfully delivers results. – toppless Apr 09 '15 at 08:43
  • PDBs are usually the issue (are you producing them in 'release' build? The reasons for not profiling an assembly/class/method are recorded in the XML output. – Shaun Wilde Apr 09 '15 at 22:52