There are a number of issues regarding the use of AltCover with the release.

Old runtimes are out of support with the latest test SDK, impacting things like long-term-stable regression tests originally built against netcoreapp3.1 or net461 and left that way. These projects will not be recognised as test projects; so one may either force relevant msbuild properties, or simply update the target runtime to one that is in support.

The Fake build system command line tool currently (5.23.x, 6.0 alpha) doesn't handle it at all - the former may work for limited scenarios, but more complicated ones fall over with library version mismatches; the latter politely asks for a v6 runtime and stops. This means going for one of the alternatives listed in the Fake.build documentation, either a full blown project building an executable, or running a script with dotnet fsi and invoking paket on the command line.

However, since net5.0, scripts are able to reference nuget packages from a script directly; so rather than having a paket.dependencies, with a #r "paket: groupref [whatever] //", and a call out to paket on the command line, your scripts can be self-contained, with a block of #r "nuget: [library][, optional version]" lines at the top, and a command line that is just dotnet fsi [my fake script.fsx].

Since rc1 there has been a serious regression, microsoft/vstest#4014, which impacts the use of command line property arguments to customise the behaviour of dotnet test, with at most one such argument being passed through to msbuild. This is apparently fixed for SDK 7.0.101, but for the moment there are workrounds, involving passing the parameters as environment variable to the test process.

Use this the function defined in this gist to intercept the TestOptions emitted by WithAltCoverOptions and similar functions and move the parameters to the environment. This gist shows an example of use.

The corresponding change is as shown in this gist

No changes needed for the instrumentation and collection phases, but if you use any of these to drive dotnet test, then test-run related properties currently passed on the command line must be pushed into the environment. For any hand-rolled command line construction, the similar property to environment variable process will have to be made by hand.