8.8.74 (2024)

.NET Core 2.1 This package targets .NET Core 2.1. The package is compatible with this framework or higher.

  • .NET CLI (Global)
  • .NET CLI (Local)
  • Cake
  • NUKE
dotnet tool install --global --version 8.8.74

This package contains a .NET tool you can call from the shell/command line.

This package contains a .NET tool you can call from the shell/command line.

#tool dotnet:?

The NuGet Team does not provide support for this client. Please contact its maintainers for support.

nuke :add-package --version 8.8.74

The NuGet Team does not provide support for this client. Please contact its maintainers for support.

  • Frameworks
  • Dependencies
  • Versions
  • Release Notes

Instrumenting coverage tool for .net (framework 2.0+ and core) and Mono assemblies, reimplemented and extended almost beyond recognition from dot-net-coverage, plus a set of related utilities for processing the results from this and from other programs producing similar output formats.


See the Wiki page for full details

What's in the box?

For Mono, .net framework and .net core, except as noted

  • altcover, a dotnet global tool for recording code coverage (netcoreapp2.1)
  • A PowerShell module for Windows PowerShell 5.1 and PowerShell Core 6+ containing a cmdlet that drives the tool, and other cmdlets for manipulating coverage reports
  • MSBuild tasks to drive the tool, including dotnet test integration (.targets file included, but as a global tool, without the frictionless integration of the core and api packages)

Why altcover?

As the name suggests, it's an alternative coverage approach. Rather than working by hooking the .net profiling API at run-time, it works by weaving the same sort of extra IL into the assemblies of interest ahead of execution. This means that it should work pretty much everywhere, whatever your platform, so long as the executing process has write access to the results file. You can even mix-and-match between platforms used to instrument and those under test.

In particular, while instrumenting .net core assemblies "just works" with this approach, it also supports Mono, as long as suitable .mdb (or .pdb, in recent versions) symbols are available. One major limitation here is that the .mdb format only stores the start location in the source of any code sequence point, and not the end; consequently any nicely coloured reports that take that information into account may show a bit strangely.

Why altcover? -- the back-story of why it was ever a thing

Back in 2010, the new .net version finally removed the deprecated profiling APIs that the free NCover 1.5.x series relied upon. The first version of AltCover was written to both fill a gap in functionality, and to give me an excuse for a ground-up F# project to work on. As such, it saw real production use for about a year and a half, until OpenCover reached a point where it could be used for .net4/x64 work (and I could find time to adapt everything downstream that consumed NCover format input).

Fast forwards to autumn 2017, and I get the chance to dust the project off, with the intention of saying that it worked on Mono, too -- and realise that it's déja vu all over again, because .net core didn't yet have profiler based coverage tools either, and the same approach would work there as well.

Continuous Integration

BuildGitHub 8.8.74 (1) 8.8.74 (2)
Test coverageCoveralls 8.8.74 (3)

Possible retirement/obsolescence of support

tl;dr -- legacy framework/Mono support is not going away any time soon.

As net472 can consume netstandard2.0 libraries (everything but the recorder), and .net core 2+ can consume net20 libraries (the recorder), legacy framework/Mono support continues until such a time as it is no longer possible to retain those API levels.

Other NuGet Packages in this suite

  • General purpose install -- excludes the dotnet test API with FAKE and CAKE integration and the AvaloniaUI visualizer
  • API install -- excludes the visualizer in all forms
  • Visualizer dotnet global tool -- just the .net core/Avalonia Visualizer as a global tool
  • FAKE build task utilities -- just AltCover related helper types for FAKE scripts (v5.23.0 or later), only in this package
  • Cake build task utilities -- just AltCover related helper types for Cake scripts (v2.0.0 or later), only in this package
Product Versions Compatible and additional computed target framework versions.
.NET net5.0 net5.0 was computed. net5.0-windows net5.0-windows was computed. net6.0 net6.0 was computed. net6.0-android net6.0-android was computed. net6.0-ios net6.0-ios was computed. net6.0-maccatalyst net6.0-maccatalyst was computed. net6.0-macos net6.0-macos was computed. net6.0-tvos net6.0-tvos was computed. net6.0-windows net6.0-windows was computed. net7.0 net7.0 was computed. net7.0-android net7.0-android was computed. net7.0-ios net7.0-ios was computed. net7.0-maccatalyst net7.0-maccatalyst was computed. net7.0-macos net7.0-macos was computed. net7.0-tvos net7.0-tvos was computed. net7.0-windows net7.0-windows was computed. net8.0 net8.0 was computed. net8.0-android net8.0-android was computed. net8.0-browser net8.0-browser was computed. net8.0-ios net8.0-ios was computed. net8.0-maccatalyst net8.0-maccatalyst was computed. net8.0-macos net8.0-macos was computed. net8.0-tvos net8.0-tvos was computed. net8.0-windows net8.0-windows was computed.
.NET Core netcoreapp2.1 netcoreapp2.1 is compatible. netcoreapp2.2 netcoreapp2.2 was computed. netcoreapp3.0 netcoreapp3.0 was computed. netcoreapp3.1 netcoreapp3.1 was computed.

Compatible target framework(s)

Included target framework(s) (in package)

Learn more about Target Frameworks and .NET Standard.

This package has no dependencies.

Version Downloads Last updated
8.8.74 2,673 5/31/2024
8.8.53 1,642 5/16/2024
8.8.21 5,032 4/15/2024
8.8.10 1,007 4/6/2024
8.7.3 5,222 3/14/2024
8.6.125 10,104 1/4/2024
8.6.95 4,183 11/14/2023
8.6.68 22,344 7/10/2023
8.6.61 8,660 6/6/2023
8.6.45 7,122 3/21/2023
8.6.40 724 3/16/2023
8.6.14 6,076 1/1/2023
8.5.842 1,060 12/25/2022
8.5.841 2,858 11/19/2022
8.4.840 1,334 10/17/2022
8.3.839 936 9/13/2022

This build from

Q. Never mind the fluff -- how do I get started?
A. Start with the Quick Start guide : and
read the FAQ :

8.8.74 (Habu series release 30)
•[BUGFIX] Issue #222 - distinguish methods differing only in number of generic parameters (JSON and cobertura in particular, but with small changes for all all output formats)
•[BUGFIX] Issue #223 - handle degenerate source paths for Cobertura output

8.8.53 (Habu series release 29)
•[BUGFIX] Fix summary data for --outputFile option
•[BUGFIX] Fix interaction of --zipFile prepare option and --outputFile collect option
•[BUGFIX] Issue #220 - improve dependency resolution to the GAC

8.8.21 (Habu series release 28)
•[BREAKING; BUGFIX] Issue #206 : Update to net6+ for dotnet test integration and respect the $(IsTestProject) setting from the Microsoft.NET.Test.Sdk package.
•Simplify the use of the AltCover MSBuild tasks via the associated package-level .targets file by not even including the VSTest integration unless both '$(AltCover)' == 'true' AND '$(IsTestProject)' == 'true'.
•Mitigate instances of System.IO.IOException: The process cannot access the file '[coverage report]' because it is being used by another process.
•Explicitly add GAC locations to the paths inspected for dependency resolution

8.8.10 (Habu series release 27)
•[BUGFIX] Add Json member to the report format enumerations for the typesafe API and for the InvokeAltCover cmdlet.
•[BUGFIX] Issue #214 : patch Mono.Cecil to use FIPS compliant algorithm
•[Enhancement] Discussion #206, maybe also Issue #203 : Option --portable and equivalent APIs to place the coverage report file and related coverage data in the same folder as the recorder assembly, wherever that might be, allowing the whole instrumented folder structure to be moved into another file structure (e.g. different machine, different OS).

8.7.3 (Habu series release 26)
•[Enhancement] Discussion 202 : More careful tidying of temporary .runsettings files, fixing long-standing errors of both commission and omission.
•[Enhancement] Discussion 199 : Add /p:AltCoverOutputRoot=[path] and associated APIs for dotnet test command line creation. The [path] is a directory to be used instead of $(TargetDir) for the relative placing of the instrumented or saved files. The use-case here is when $(TargetDir) is close to MAX_PATH and the generated sub-folders would overflow that limit.

For previous releases (8.6.125 and earlier) go here -- 8.8.74 (2024)
Top Articles
Latest Posts
Article information

Author: Gregorio Kreiger

Last Updated:

Views: 6594

Rating: 4.7 / 5 (57 voted)

Reviews: 80% of readers found this page helpful

Author information

Name: Gregorio Kreiger

Birthday: 1994-12-18

Address: 89212 Tracey Ramp, Sunside, MT 08453-0951

Phone: +9014805370218

Job: Customer Designer

Hobby: Mountain biking, Orienteering, Hiking, Sewing, Backpacking, Mushroom hunting, Backpacking

Introduction: My name is Gregorio Kreiger, I am a tender, brainy, enthusiastic, combative, agreeable, gentle, gentle person who loves writing and wants to share my knowledge and understanding with you.