1

If I install OpenCover into a solution via NuGet, I get the expected files under, e.g., a packages\OpenCover.4.5.1604 folder. However, OpenCover's profilers require COM registration in order to function properly. I recognize that it's possible to use a -register command to do a run-time registration of these, but on a machine with multiple solutions, which may potentially have different versions of OpenCover installed (and which could be executing them simultaneously -- e.g., a build server), this seems problematic.

This SO answer from the author himself indicates that calling regsvr32 separately to register the profilers once would be preferable on a build server, and that makes sense. But in the situation where OpenCover has been pulled down via NuGet (into the solution), is there a proper build server solution? Or is NuGet simply a convenient way to get the files, but they should really be copied to a centralized location and then registered, rather than attempting to be run from a solution-specific version?

Community
  • 1
  • 1
Nick Jones
  • 4,395
  • 6
  • 33
  • 44

1 Answers1

0

On my build machines (using opencover pulled via nuget) I use the -register:user option; this registers it for that user account and is deregistered after execution of the target process.

OpenCover also registers a key that it uses to talk to the profilers that are related to just those processes it executes, that way multiple OpenCover consoles can run in parallel if required; OpenCover has a dogfood test called pedigree (opencover executing opencover executing nunit) that exercises that functionality.

However my build machines only runs one build-script at a time. Most build machine agents do this because it is usually quicker, which one are you using?

If you have a scenario that OpenCover doesn't handle please raise the issue on the forum - otherwise happy testing.

Shaun Wilde
  • 8,228
  • 4
  • 36
  • 56
  • Thanks Shaun. We're using Jenkins and have several (4, currently) executors due to the quantity of build jobs it supports; simultaneous executions of different jobs -- different projects, in different workspace folders -- are possible, though simultaneous executions of the same job are not. The Jenkins service is running as LocalSystem. – Nick Jones Jul 02 '13 at 20:04
  • Try the `-register:user` option. If that doesn't work there is another environment variable that could be utilised [COR_PROFILER_PATH](http://msdn.microsoft.com/en-us/library/ee471451.aspx) which I don't use (yet) you could set that yourself and then run OpenCover without the `-register` switch. – Shaun Wilde Jul 05 '13 at 22:05
  • Thanks Shaun, this looks like it could help. – Nick Jones Jul 10 '13 at 16:09
  • The link to the GitHub issue is now https://github.com/opencover/opencover/issues/164 – Nick Jones Apr 23 '14 at 21:54
  • For what it's worth, -register:user didn't actually work on my build server; it resulted in `"No results, this could be for a number of reasons. The most common reasons are: 1) missing PDBs for the assemblies that match the filter please review the output file and refer to the Usage guide (Usage.rtf) about filters. 2) the profiler may not be registered correctly, please refer to the Usage guide and the -register switch."`. But the new -register:path64 seems to work. – Nick Jones Apr 23 '14 at 22:01
  • I should also note that "-register" was mostly working; every so often it failed for unclear reasons. So I'm not certain that -register:path64 will fare any better. – Nick Jones Apr 23 '14 at 22:06