Bug in Profiler

[pa-sleo]

Please provide the following information when submitting an issue.

Where appropriate replace the [ ] with a [X]

My Framework

• .NET 2
• .NET 3.5
• .NET 4
• .NET 4.5
• .NET 4.6
• .NET 4.6.1
• .NET 4.6.2
• .NET Core 1.0.0
• Something else

My Environment

• Windows 7 or below (not truly supported due to EOL)
• Windows 8
• Windows 8.1
• Windows 10
• Windows 10 IoT Core
• Windows Server 2012
• Windows Server 2012 R2
• Windows Server 2016

I have already...

• repeated the problem using the latest stable release of OpenCover.
• reviewed the usage guide and usage document.
• have looked at the opencover output xml file in an attempt to resolve the issue.
• reviewed the current issues to check that the issue isn't already known.

My issue is related to (check only those which apply):

• no coverage being recorded
• 32 or 64 bit support
• feature request

Expected Behavior

All assemblies loaded in the application domain which arent excluded by a filter should be tracked.

Actual Behavior

Assemblies won't be tracked if there is a large assembly e.g (5820 classes). This comes from the fact that there is a timeout in the ProfilerCommunication class in the profiler project. The timeout is specified as COM_WAIT_LONG which is 60000 ms. This is not enough for building the instrumentation model. The Method is: TrackMethod. I think the correct value should be the value of the variable: _short_wait of the same class.

I also think it would be neccessary to allow the specifiaction of the variable by the commandline not only by environment variable.

Steps to reproduce the problem:

Create a large assembly with more than 5000 complex classes and try to profile that.

I use open Cover for integration testing.

[kevinbosman]

I've encountered the same problem trying to cover a legacy assembly with just a handful of very large methods (>5000 lines each)

I also found that the Profiler timeouts are far too short.

The COM_WAIT_LONG timeout is hard coded at 60 seconds and the _short_wait, while it can be configured via the -communicationtimeout command line option, has an artificially imposed maximum limitation also of just 60 seconds.

I found that in my case I needed to increase BOTH the COM_WAIT_LONG timeout AND the _short_wait to at least 240 seconds, otherwise it was silently timing out with either zero coverage or the dreaded No results, this could be for a number of reasons failure. EDIT Note that in the latter case, the xml output did not have a reference to the assembly under test at all.

I would also suggest and request:

1. using _short_wait in place of COM_WAIT_LONG in TrackAssembly() here

   opencover/main/OpenCover.Profiler/ProfilerCommunication.cpp

   Line 466 in 67980c8

   , COM_WAIT_LONG

2. removing the artificial 60s upper limit on the -communicationtimeout command line option here

   opencover/main/OpenCover.Framework/CommandLineParser.cs

   Line 248 in 67980c8

   CommunicationTimeout = Math.Max(Math.Min(CommunicationTimeout, 60000), 10000);

   and on _shortwait in OpenCoverInitialise() here

   opencover/main/OpenCover.Profiler/CodeCoverage.cpp

   Lines 135 to 136 in 67980c8

   	if (_shortwait > 60000)
   	_shortwait = 60000;

[MarkKharitonov]

This seems to be exactly our issue - could not get any coverage at all. I switched over to dotCover because of this.