Could not copy. The process cannot access the file because it is being used by another process

5
votes

I am getting the following error when running my build on Visual Studio Online (using the built-in Build Controller):

C:\Program Files (x86)\MSBuild\14.0\bin\amd64\Microsoft.Common.CurrentVersion.targets (3962): Could not copy "d:\a\src\MySolution\MyProject\Trunk\packages\Microsoft.Data.Edm.5.6.4\lib\net40\Microsoft.Data.Edm.xml" to "..\Build\bin\Release\Microsoft.Data.Edm.xml". Beginning retry 1 in 1000ms. The process cannot access the file '..\Build\bin\Release\Microsoft.Data.Edm.xml' because it is being used by another process.

It is never the same file either but it seems to always be either an xml or dll from the packages folder.

EDIT: I'm not sure if it is worth mentioning, but I do have multiple workspaces and multiple build definitions using this repository.

2
tfsmsbuildazure-devops
Try passing the MSbuild argument /m:1 to reduce the number of processors used to build to 1. – Daniel Mann
I'm not sure if it is worth mentioning, but I do have multiple workspaces and multiple build definitions using this repository. – Dave New

2 Answers

4
votes

I found the problem. Completely unrelated to the error above.

I went into the msbuild log files and found this:

Failed to produce diagnostics extension's config for MyRole\diagnostics.wadcfgx. Error : Could not find a part of the path 'd:\a\src...\MyRole\diagnostics.wadcfgx'. Done Building Project "d:\a\src...\MyCloudProject.Cloud.ccproj" (Publish target(s)) -- FAILED.

I was missing a file in source control.

I do wonder why this error did not bubble up into my build summary. And where did that initial error come from?

1
votes

I am using TFS with Using Visual Studio 2013 and have been able to work around this issue by closing all open documents that I want to check-in (seems VS locked itself out) and/or resolving conflicts. The error message is sufficiently vague so as to be useless as to the actual cause of the check-in failure.

Update 02 November 2016:

I'm not sure why VS 2013 and TFS don't play nice together via the Team Explorer Check-in Pending Changes button, but it consistently fails to launch the conflict resolver, a key piece of the check-in process.

The following works for me on VS 2013 and TFS hosted on a SQLServer Express 2014 database: 1. Launch the Source Explorer: Team Explorer tab -> Source Explorer
2. Navigate to your solution repository 3. Then proceed to do the following for each project that you want to check in: a. Right click project b. Check in pending changes c. Resolve conflicts and repeat steps 3a and 3b until no pending changes remain for the project