Frequently Asked Questions

  1. What is code coverage analysis?
  2. Why would I want to do code coverage analysis?
  3. What makes NCover better than other code coverage tools?
  4. Which programming languages does NCover support?
  5. Does NCover require a special compilation step for my code?
  6. How does NCover work?
  7. What kind of output does NCover produce?
  8. What does the XML output look like?
  9. Is there a graphical interface? A command line utility?
  10. How do I use coverage exclusions?
  11. Can I use NCover with 64-bit programs? How?
  12. Troubleshooting: Why don't I get coverage for Automatic Properties?
  13. Troubleshooting: Why is my coverage.xml file empty?
  14. Troubleshooting: I have coverage.xml output but my XYZ assembly is not included in it?
  15. Troubleshooting: After running NCover my coverage.log says "Failed to load symbols for module XYZ"?
  16. Troubleshooting: I get a "Profiled process terminated. Profiler connection not established" message?
  17. Troubleshooting: My coverage exclusions are not working?
  18. Where can I get additional help or support?

1. What is code coverage analysis?

A code coverage analyzer monitors your code at runtime and records information about which lines of code were executed. NCover shows each sequence point in your application along with the number of times that point was executed. Sequence points are generated by the compiler and stored in the debug information (.pdb) files. A sequence point basically corresponds to a single program statement (often a line of code) in your high-level language.

2. Why would I want to do code coverage analysis?

Unit test suites are often used as a quality tool during the development process to keep the codebase stable as it changes and expands. Tools such as NUnit are often used to run and report on the test suites. However, when implementing unit testing in your build process, you have no way of knowing how much of your code the unit tests are actually testing. This is where code coverage comes in. You can run NUnit within NCover and use the code coverage report to determine which code was not tested by that particular test suite.

3. What makes NCover better than other code coverage tools?

Unlike most code coverage tools, NCover does not modify your source code in any way to generate coverage information. This means that you get coverage based on real, production code, providing more accurate data. For more information about how NCover works, see "Does NCover require a special compilation for my code?" and "How does NCover work?"

4. Which programming languages does NCover support?

In short, any .NET programming language. NCover requires the .NET framework version 2.0.50727 to be installed; however, the application being profiled can be written against any shipping version of the framework. NCover has been tested profiling coverage of .NET 2.0, .NET 1.1 and .NET 1.0 applications. Note that NCover derives a lot of information from debugging symbols (.PDB files), which are not governed by any standard. This means that different languages and compilers will yield slightly different output.

5. Does NCover require a special compilation step for my code?

No. NCover is designed to work on shipping code by using the .NET Framework profiling API to monitor your code. It does require build symbols, but can be run on release code without any modifications. Note that debugging symbols may not be enabled by default in your particular programming environment. Changing this is typically as simple as adding an additional command line flag or project setting.

6. How does NCover work?

NCover uses the .NET Framework profiler API to monitor an application's execution. When a method is loaded by the CLR, NCover retrieves the IL and replaces it with instrumented IL code. NCover does not change your original IL code, it simply inserts new code to update a visit counter at each sequence point. Upon request, (usually after the .NET process has shut down) the profiler outputs statistics to the coverage file.

7. What kind of output does NCover produce?

By default, NCover outputs an xml file:

Another option available to Enterprise Edition users is the HTML output command line flag (//h). This generates a redistributable directory structure that can be viewed in any Web Browser.

8. What does the XML output look like?

Here is an example of the XML output:

<method name="ExternalThrownException" signature="ExternalThrownException() : void" excluded="false" instrumented="true">

  <seqpnt vc="1" l="40" el="40" c="17" ec="43" ex="false" fl="65536" doc="0" /> 
  <seqpnt vc="0" l="41" el="41" c="17" ec="59" ex="false" fl="65536" doc="0" /> 
  <seqpnt vc="0" l="16707566" el="16707566" c="0" ec="0" ex="true" fl="197121" doc="0" /> 
  <seqpnt vc="1" l="42" el="42" c="15" ec="34" ex="false" fl="65536" doc="0" /> 
  <seqpnt vc="1" l="43" el="43" c="17" ec="46" ex="false" fl="65536" doc="0" /> 
  <seqpnt vc="0" l="16707566" el="16707566" c="0" ec="0" ex="true" fl="197121" doc="0" /> 
  <seqpnt vc="1" l="45" el="45" c="9" ec="10" ex="false" fl="196608" doc="0" />

</method>

9. Is there a graphical interface? A command line utility?

NCover provides both a graphical interface (NCoverExplorer) and a command line utility (NCover.Console).

10. How do I use coverage exclusions?

First you should define an attribute to markup your excluded code with. You will likely want to put this in a common assembly to make it reusable, or indeed within a "CommonAssemblyInfo.cs" that you include in all your application assemblies. 

namespace MyNamespace {
    class CoverageExcludeAttribute : System.Attribute { }
}

Apply the attribute to the C# classes and/or methods you wish to mark as excluded from code coverage statistics 

[CoverageExcludeAttribute]
private void SomeMethodToExclude() {}

Finally, ensure you pass the full qualified attribute information in the NCover command line:

NCover.Console MyApplication.exe //ea MyNamespace.CoverageExcludeAttribute

Note that if you are using the TestDriven.Net VS.Net add-in to "Test with Coverage" it will automatically pass through "//ea CoverageExcludeAttribute" which you should define without a namespace like above.

11. Can I use NCover with 64-bit programs? How?

If you are using the Enterprise edition, yes. To profile 64-bit applications, you must have used the 64-bit installer, available from the download page. Otherwise, it is no different than profiling a regular 32-bit application.

12. Troubleshooting: Why don't I get coverage for Automatic Properties?

Automatic Properties are syntactic sugar supported by the VS 2008 C# compiler. Unfortunately, the compiler doesn't emit any symbols for Automatic Properties, so NCover (since it depends on the symbols generated by the compiler and placed in the PDBs) isn't even aware that an Automatic Property exists. However, NCover does produce Branch Coverage for Automatic Properties. Unfortunately, NCoverExplorer doesn't support branch points, so to see the branch coverage data for the automatic properties, you'll have to generate an HTML report from NCover.Console by using the //h flag.

13. Troubleshooting: Why is my coverage.xml file empty?

Your coverage.xml file was empty because NCover was unable to locate the debug symbol files for the assemblies profiled. This could happen because the assemblies were loaded from the GAC, in which case you should either uninstall the assemblies from the GAC, or move the .pdbs into the GAC.

One other reason NCover generates an empty coverage.xml file is because the assemblies were loaded from NUnit's shadow copy. By default, NUnit shadow copies your assemblies before it tests them, and in some cases, the .pdb files aren't copied with the assemblies. The easiest way to fix this problem is to run NUnit with the /noshadow command.

Finally, the //ssp argument might be too restrictive. Grant Drake has an excellent help page on empty coverage.xml files here.

14. Troubleshooting: I have coverage.xml output but my XYZ assembly is not included in it?

15. Troubleshooting: After running NCover my coverage.log says "Failed to load symbols for module XYZ"?

This message means that no .pdb build symbol file was found for that assembly so it cannot be profiled for code coverage. If that assembly is part of the .NET framework for instance like System.Data.dll, then this is an expected message and should not cause concern. If however the assembly belongs to your application, did you generate the build symbol files (.pdb files) for it?

16. Troubleshooting: I get a "Profiled process terminated. Profiler connection not established" message?

This message means that NCover was unable to find the NCover.Lib dll. Run NCover with the //reg argument to force the dll to register so that NCover can find it. Grant Drake offers some advice on this topic here.

17. Troubleshooting: My coverage exclusions are not working?

Have you put the full namespace type name to the exclusion including the Attribute suffix in the //ea argument? See the "How do I use coverage exclusions?" question above.

18. Where can I get additional help or support?

If your question is not answered here, we recommend taking a look at the forums. If you still can't find a solution to your issue, you can either post a new thread on the forum or submit a support ticket.