altcover.cake 8.9.3

.NET Core 3.1 This package targets .NET Core 3.1. The package is compatible with this framework or higher. .NET Standard 2.0 This package targets .NET Standard 2.0. The package is compatible with this framework or higher.
There is a newer version of this package available.
See the version list below for details. 
dotnet add package altcover.cake --version 8.9.3                

                    
                

            
NuGet\Install-Package altcover.cake -Version 8.9.3
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package. 
<PackageReference Include="altcover.cake" Version="8.9.3" />
For projects that support PackageReference, copy this XML node into the project file to reference the package. 
paket add altcover.cake --version 8.9.3                

                    
                

            
#r "nuget: altcover.cake, 8.9.3"
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package. 
// Install altcover.cake as a Cake Addin
#addin nuget:?package=altcover.cake&version=8.9.3

// Install altcover.cake as a Cake Tool
#tool nuget:?package=altcover.cake&version=8.9.3

altcover.cake

Contains options to run AltCover as part of dotnet test within a Cake build script.

Usage

Given specifications prepare, process and collect (part of the API), extend a dotnet test invocation with coverage collection

{
    // do any required customizations here
    var altcoverSettings = new AltCover.Cake.CoverageSettings {
        PreparationPhase = prepare,
        CollectionPhase = collect,
        Options = process
    };

    var testSettings = new DotNetCoreTestSettings {
        Configuration = configuration,
        NoBuild = true,
    };

    DotNetCoreTest(<project to test>, // or DotNetTest at v2 or v3
                      testSettings, altcoverSettings);
});

See the Wiki page for full details

What's in the box?

APIs for integration into Cake build scripts (at netstandard2.0 for v1, and netcoreapp3.1 for v2 and v3 Cake APIs)

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
Build GitHub Build statusBuild history
Test coverage Coveralls Coverage Status

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

Product Compatible and additional computed target framework versions.
.NET net5.0 was computed.  net5.0-windows was computed.  net6.0 was computed.  net6.0-android was computed.  net6.0-ios was computed.  net6.0-maccatalyst was computed.  net6.0-macos was computed.  net6.0-tvos was computed.  net6.0-windows was computed.  net7.0 was computed.  net7.0-android was computed.  net7.0-ios was computed.  net7.0-maccatalyst was computed.  net7.0-macos was computed.  net7.0-tvos was computed.  net7.0-windows was computed.  net8.0 was computed.  net8.0-android was computed.  net8.0-browser was computed.  net8.0-ios was computed.  net8.0-maccatalyst was computed.  net8.0-macos was computed.  net8.0-tvos was computed.  net8.0-windows was computed. 
.NET Core netcoreapp2.0 was computed.  netcoreapp2.1 was computed.  netcoreapp2.2 was computed.  netcoreapp3.0 was computed.  netcoreapp3.1 is compatible. 
.NET Standard netstandard2.0 is compatible.  netstandard2.1 was computed. 
.NET Framework net461 was computed.  net462 was computed.  net463 was computed.  net47 was computed.  net471 was computed.  net472 was computed.  net48 was computed.  net481 was computed. 
MonoAndroid monoandroid was computed. 
MonoMac monomac was computed. 
MonoTouch monotouch was computed. 
Tizen tizen40 was computed.  tizen60 was computed. 
Xamarin.iOS xamarinios was computed. 
Xamarin.Mac xamarinmac was computed. 
Xamarin.TVOS xamarintvos was computed. 
Xamarin.WatchOS xamarinwatchos was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

NuGet packages

This package is not used by any NuGet packages.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last updated
9.0.1 70 11/14/2024
8.9.3 124 8/17/2024
8.8.173 83 7/27/2024
8.8.165 94 7/23/2024
8.8.74 112 5/31/2024
8.8.53 99 5/16/2024
8.8.21 124 4/15/2024
8.8.10 126 4/6/2024
8.7.3 119 3/14/2024
8.6.125 209 1/4/2024
8.6.95 191 11/14/2023
8.6.68 2,964 7/10/2023
8.6.61 173 6/6/2023
8.6.45 243 3/21/2023
8.6.40 229 3/16/2023
8.6.14 361 1/1/2023
8.5.842 334 12/25/2022
8.5.841 332 11/19/2022

This build from https://github.com/SteveGilham/altcover/tree/af20985812b322ad5cd49969c25bcef63d7ca840

Q. Never mind the fluff -- how do I get started?
A. Start with the Quick Start guide : https://github.com/SteveGilham/altcover/wiki/QuickStart-Guide and
read the FAQ : https://github.com/SteveGilham/altcover/wiki/FAQ

8.9.3 (Habu series release 33)
• Add -p/--package and equivalents to specify package roots for Cobertura output for all coverage collection methods, plus the PowerShell ConvertTo-Cobertura cmdlet
• [ADVISORY] The Fake.build related assemblies (in the altcover.api and altcover.fake packages) support Fake 6.1.0
• [PERFORMANCE] revise the OpenCover to LCov conversion to speed the mapping of methods from source files.

8.8.173 (Habu series release 32)
• [PERFORMANCE] Issue #227 - removing the slow-down observed the new (at 8.8.165) file name processing for Cobertura
• [PERFORMANCE] removing a surprising hot-spot in branch coverage instrumentation that was taking 60% of the whole instrumentation time

8.8.165 (Habu series release 31)
• [ADVISORY] the Fake.build related assemblies (in the altcover.api and altcover.fake packages), and the Avalonia 0.10-based visualizer, rely on components with known vulnerabilities. The Fake.build project appears nigh-moribund so has not released an update, whereas Avalonia 11 completely rewrites all the earlier APIs and has not documented anything to assist in the rewrite of the application.
• [BUGFIX] Issue #197 - correctly split file paths in the Cobertura output
• [NET9 preparation] Recode the recorder into C# as compiler/build target changes in F#9 make maintaining net2.0 compatibility in F# too much bother.

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 -- https://github.com/SteveGilham/altcover/blob/master/ReleaseNotes%20-%20Previously.md