Common Coverage Issues

No Coverage

Then

In previous versions of NCover, a common issues was code #20000 -- 'no data was collected.' This problem was often caused when the wrong process name was specified, or NCover made a bad guess as to what the process name should be.

If no messages were included in NCover's output showing that a process had begun profiling you'd need to add either //coverall (profile all subprocesses) or //pn (specify process name) arguments to ensure that NCover collected coverage for the target process.

Now

It's much less likely that NCover Desktop will fail to find a dependent process. NCover runs as a Windows service and is constantly monitoring, waiting to profile new processes and automatically track their dependencies.

Bitness

Then

In NCover 3, it was common to have errors caused by a mismatch between the bit depth of NCover and the bit depth of the profiled executable or DLL. It was the user's responsibility to make sure the bitness of both NCover and the profiled code matched, so that coverage could succeed.

Now

When you install NCover Desktop, both 32 and 64 bit versions are installed and managed automatically, so there's no need to choose which version you need and install separately. It's also no longer necessary to determine and specify which version of NCover to run based on the bitness of your covered applications.

Source Code Highlighting

Then

In NCover 3, it was not unusual to see a method with with green highlighting to indicate coverage for all lines of source code, but branch coverage numbers of less than 100% and no obvious way to explain the missed coverage.

Now

NCover Desktop features new Branch visualization that makes missed branches easier to spot, even if they occur within lines of code that are covered from the perspective of visit counts.

IIS Coverage

Then

NCover would automatically monitor the w3wp.exe and aspnet_wp.exe processes, then start the World Wide Web Publishing Service. The NCover profiler could not connect until you loaded an ASP.NET page, then the w3wp process had to be stopped (either manually or programmatically) before coverage could be gathered.

Now

NCover Desktop runs as a service and is constantly monitoring, waiting to profile a new process. As ASP.NET pages are loaded, NCover will collect information on them until the covered application (if any) and the service ends or is stopped.