`dotnet test /p:AltCover=true /p:AltCoverInPlace=true` results in System.IO.IOException: The process cannot access the file 'C:\src\testprj\bin\Debug\net8.0\AltCover.Recorder.g.dll' because it is being used by another process. about altcover HOT 5 CLOSED

I get the same result when running my tests of my project as well.

dotnet test /p:AltCover=true /p:AltCoverAssemblyExcludeFilter="Microsoft|testhost|NUnit3.TestAdapter|AltCover.Monitor|GreenFeetWorkFlow.Tests" works

from altcover.

This is an unfortunate effect of the way that, on Windows, at least, file locks can take some appreciable time to release even after the process that took them out has exited, so the dotnet test script takes a back-off and retry approach when it encounters such a lingering lock.

What is going on is that with the --inplace option, the as-built files are saved away, and instrumented files, including the generated recorder assembly are placed in the build target directory. The dotnet test script runs the test, runs the coverage collection (which involves reading the location of the coverage report from the recorder), then goes to restore the target directory to the original state, copying back the uninstrumented files and deleting the added recorder assembly - and it's this last step that's causing the observed behaviour.

Changes that can be made would be cosmetic - not just echoing the exception message, but putting out something more anodyne; and increasing the retry frequency.

from altcover.

The message is emitted only after a number of attempts have failed; so I've added some mitigations - tightening the scope of the use of the recorder file, so the locks will be released sooner, increasing the frequency of retries, and finally replacing the exception message with a more informational Failed to delete file [name].

from altcover.

Release 8.8.21 mitigates the likelihood of the issue, and improves the resulting error message if the file cannot be promptly deleted.

from altcover.

Assuming sufficiently resolved.

from altcover.