Coverlet.Collector.Utilities.CoverletDataCollectorException failing to access a DLL because it is being used by another process #1224
Labels
Known Issue
It's a know issue
Comments
|
Looks like that command you reported is running instrumentation/tests multiple time overlapped. |
|
I can confirm this issue. It happens only sometimes (about 1 in 50 builds). We are using the recommended VSTest integration (coverlet.collector package). This is how we call it (via Cake Frosting): this.DotNetCoreTest(BuildSettings.SolutionFile, new DotNetCoreTestSettings
{
Collectors = new List<string> { "XPlat Code Coverage" },
Configuration = BuildConfig,
ResultsDirectory = TestReportsDir,
NoBuild = true,
NoRestore = true,
Filter = "FullyQualifiedName!~End2End&FullyQualifiedName!~Integration",
ArgumentCustomization = args =>
{
args.AppendMSBuildSettings(new DotNetCoreMSBuildSettings { MaxCpuCount = 1 }, environment: null);
args.Append(" -- DataCollectionRunSettings.DataCollectors.DataCollector.Configuration.IncludeTestAssembly=false");
return args;
},
}); |
|
We've only been using the VSTest integration for 1.5 months so I can't say if the problem came with an update of the package. But the timing issue described by OP seems likely, because our build machine sometimes faces heavy load in which case build jobs will take longer than usual. |
Relevant part of our build logInterestingly |
|
The issue looks like is related to "restore" instrumented file after tests https://github.com/coverlet-coverage/coverlet/blob/master/src/coverlet.core/Helpers/InstrumentationHelper.cs#L218 so for some reason that files are locked by someone, usually are antivirus o some other tool. |
|
A past idea was add a flag like |
MarcoRossignoli
added
Priority:1
|
Hi @MarcoRossignoli, thanks for looking into this! I think such a flag would work for us. We can always throw away the build after coverage analysis and make a new one for deployment. My gues is, if it really is some anti-virus software then there is isn't much that can be done anyway. The build machine is not fully under our control (as it is the case in many CI scenarios, I imagine). |
|
coverlet retries more times during restore but looks like in this case is not enough |
|
Getting this error in around 1 out of 10 builds. The problem is, the entire process runs, and in the end, the coverage report remains incomplete. |
|
I am still getting The process can not access the file because it is being used by another process. Is it fixed? |
|
Hi, we are experiencing same issue after upgrading from version 3.2.0 to 6.0.0. Any progress with fix? |
|
Hello, |
Bertk
removed
feature-request
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
We're recently hitting this error when we made a change:
We're using the latest version: https://www.nuget.org/packages/coverlet.collector/3.1.0
Command we're using to run:
This is currently blocking a change we need to diagnose a failure ..
There seems to be some timing issue that's affecting this - e.g.:
The text was updated successfully, but these errors were encountered: