-
Notifications
You must be signed in to change notification settings - Fork 386
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Coverlet.Collector.Utilities.CoverletDataCollectorException failing to access a DLL because it is being used by another process #1224
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 log
Interestingly |
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 |
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,
|
Consider adding |
Looks like 2 problems are mentioned in this issue original: comment: @jeofyoung Could you please check whether the workaround eliminates the original problem as well
|
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: