TFS 2012 Build "Access to Path Denied"

Question

I’m using TFS 2012 Build and running into an error

Access to the path is denied

The solution being built contains about 15 projects of which a number are using the Castle.Components.Validator.2.5.0 assembly.

I have seen other posts that talk about the TFS Build Access Denied errors, but they generally refer to having simultaneous builds running. In this case only one build runs at a time. Also, the error occurs when the server is restarted or the build has not run for some time.

Once a build is run and fails, the next one succeeds and each one after that succeeds again until the build hasn’t been run for a while or the server is restarted. Although we can get around this, it is a manual headache.

Here is the error:

C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets (3513): Unable to copy file "D:\Builds\12\Foo\Check-In Build\Sources\packages\Castle.Components.Validator.2.5.0\lib\NET40\Castle.Components.Validator.dll" to "D:\Builds\12\Foo\Check-In Build\Binaries\Castle.Components.Validator.dll".
Access to the path 'D:\Builds\12\Foo\Check-In Build\Binaries\Castle.Components.Validator.dll' is denied.

When looking at the log file you can see that the build is trying to copy the file twice. Because the first one has a lock on the file, the second one fails and thus the build fails. Here is a snippet of the log file that shows what is happening:

2>_CopyFilesMarkedCopyLocal: Copying file from "D:\Builds\12\Foo\Check-In Build\Sources\packages\Castle.Components.Validator.2.5.0\lib\NET40\Castle.Components.Validator.dll" to "D:\Builds\12\Foo\Check-In Build\Binaries\Castle.Components.Validator.dll".
5>_CopyFilesMarkedCopyLocal: Copying file from "D:\Builds\12\Foo\Check-In Build\Sources\packages\Castle.Components.Validator.2.5.0\lib\NET40\Castle.Components.Validator.dll" to "D:\Builds\12\Foo\Check-In Build\Binaries\Castle.Components.Validator.dll".
2>_CopyFilesMarkedCopyLocal: Copying file from "D:\Builds\12\Foo\Check-In Build\Sources\packages\MvcContrib.Mvc3.FluentHtml-ci.3.0.96.0\lib\MvcContrib.FluentHtml.dll" to "D:\Builds\12\Foo\Check-In Build\Binaries\MvcContrib.FluentHtml.dll". Copying file from "D:\Builds\12\Foo\Check-In Build\Sources\packages\RhinoMocks.3.6\lib\Rhino.Mocks.dll" to "D:\Builds\12\Foo\Check-In Build\Binaries\Rhino.Mocks.dll".

Any help on how to fix this would be greatly appreciated.

Mike Asdf · Answer 1 · 2016-08-29T16:43:17.123

As others mentioned, this happens when performing multithreaded builds with a common destination directory and the file copy task happens to encounter a simultaneous conflict with a copy task running for a different project.

Normally this should result in a "file used by another process" exception (which is handled and retried by the file copy task) but sometimes the file operation results in an "Access is denied" exception instead. (I'm still not sure why)

Some suggest that you should "solve the duplication", but I don't see that as being feasible for cases where all the projects need to directly reference a library like log4net.

Obviously one way to prevent the issue is to explicitly run msbuild with /p:BuildInParallel=false or /m:1 or /maxcpucount:1 (or omit the argument entirely) to force single-threaded mode.

However, in TFS 2013, the default build template automatically always passes /m (use all cores) to msbuild, which silently overrides any single-thread setting you can manually pass in. (Determined by my own experimentation and examining diagnostic logs)

Another workaround I attempted was to manually pass /p:AllowedReferenceRelatedFileExtensions=none to msbuild, which prevents all pdb and xml files from being copied from referenced libraries. (Since for a while I only ever saw xml files having this issue.) But then I kept having problems with log4net.dll.

The ultimate workaround that I used was one I discovered by decompiling the source code for Microsoft.Build.Tasks.Copy:

if (hrForException == -2147024891)
{
    if (!Copy.alwaysRetryCopy)
        throw;
    else
        this.LogDiagnostic("Retrying on ERROR_ACCESS_DENIED because MSBUILDALWAYSRETRY = 1", new object[0]);
}

If error -2147024891 (0x80070005 access is denied) occurs, the Copy task will check a special variable to see if it should retry. That value is set via an environment variable:

Copy.alwaysRetryCopy = Environment.GetEnvironmentVariable("MSBUILDALWAYSRETRY") != null;

After setting the environment variable MSBUILDALWAYSRETRY = 1 (and restarting the build server), the problem went away. And I also periodically started seeing "Retrying on ERROR_ACCESS_DENIED..." as warnings in the build logs, proving that the setting was taking effect, (instead of the builds merely coincidentally succeeding).

(Note that this environment variable is not well documented, use as appropriate.)

Update: Apparently TFS 2015 no longer overrides your /m:1 with /m (even on legacy/XAML build definitions), which should make /m:1 a valid fix again.

TfvcTemplate.12.xaml seems to work with /m:1 but not with /p:BuildInParallel=false — felickz, Jun 09 '14 at 19:50
This MSBUILDALWAYSRETRY hack is disgusting, but at least it lets me know that MS is as fed up with this nonsense as I am, and that there is indeed nothing I'm missing. Time to add another step to my build server spin-up checklist. — bwerks, Jul 21 '14 at 04:43
I used MSBUILDALWAYSRETRY = 1 and now I'm getting "Exceeded retry count of 10. Failed." Any clues? — user20358, Oct 13 '14 at 10:56
@user20358 If it happens consistently that almost sounds like a filesystem permissions issue. — Mike Asdf, Oct 13 '14 at 19:14
Here is a powershell snippet to create the **environment variable** and restart the **TFS host service** (*name depends on TFS Controller version*) `[Environment]::SetEnvironmentVariable("MSBUILDALWAYSRETRY", "1", "Machine")` `restart-Service TFSBuildServiceHost.2012` — SliverNinja - MSFT, May 19 '15 at 16:29

score 41 · Accepted Answer · answered Oct 16 '12 at 00:30

41

It looks like there are two projects copying the same file. Depending on the timing, they sometimes happen at the same time, resulting in the failure. You have to trace the node id back to find the source project. See http://blogs.msdn.com/b/buckh/archive/2012/01/21/a-tool-to-find-duplicate-copies-in-a-build.aspx for more details and code that may track it down for you.

answered Oct 16 '12 at 00:30

Buck Hodges

3,342
1
19
20

6

Buck - Thank you for your quick response. Your comment and link were useful in understanding the problem. The old build server we used was not a multi-proc server and therefore the build only ran with one proc. Our new build server is multi-proc and now the builds were executing on multiple processors which lead to the file collision. In this particular case, there isn't a need to speed up the build so I changed the setting MSBuild Multi-Proc(under Process/Advanced in the Build Process Template) to False. And in fact, it had an unnoticeable impact on the build performance. – Nimblejoe Oct 16 '12 at 01:30
3

As another option in this case if I needed Multi-proc capacity, I know what projects are sharing using this reference and I would come up with a strategy like setting the projects to CopyLocal = False for this assembly and use a shared folder directory where the projects could reference the assembly instead. – Nimblejoe Oct 16 '12 at 01:31

score 13 · Answer 3 · answered Oct 02 '13 at 12:56

13

As Buck Hodges and Nimblejoe have rightly said, this is mostly due to TFS running multiple MSBuild processes by default to build your projects.

You can override it in the build definition in Process -> 3. Advanced -> MSBuild Arguments by adding the MSBuild argument /p:BuildInParallel=false

answered Oct 02 '13 at 12:56

Ace

1,392
3
14
20

4

@stuartd this was removed in 2013 TfvcTemplate.12.template http://www.garyhowlett.co.uk/2013/11/07/adding-back-the-msbuild-multiproc-option-in-tfvctemplate-12-xaml/ – felickz Jun 09 '14 at 13:14
1

@felickz The setting still exists if you edit the template under the `Run MSBuild` build activity parameters (listed under `MSBuildMultiProc`). – Jon Peterson Jun 09 '14 at 18:21

score 11 · Answer 4 · answered Mar 24 '14 at 18:11

11

This can also happen if you have a build agent's folder open.

answered Mar 24 '14 at 18:11

StingyJack

19,041
10
63
122

1

It's a minor point, but I believe those errors present as "Folder was not empty" or something along those lines, rather than access denied. Certainly a good thing to be aware of, though. – bwerks Jul 20 '14 at 20:27
They were access denied for the latest scenario. I remember because the same guy caused it to himself like 4 times in a row and I had to send a note out to the team about it. We do get a random "folder not empty" from time to time also, but its not because someone has the folder open. – StingyJack Jul 22 '14 at 00:46
I was scratching my head and then realized this was the cause of my problem lol – The Muffin Man Apr 06 '15 at 23:46
This was the cause of my problem too, but oddly if I tried to browse to the folder in question it did also come up with an access denied message in file exporer... – dougajmcdonald Apr 16 '15 at 08:52

score 8 · Answer 5 · answered Dec 30 '14 at 18:10

I also had same problem. I got error messages that related to cannot copy since access to path denied. In my case all my dll's and xml files and so on are place at D:\TFS\Example\Bin\Debug folder.

I right clicked on Bin folder and clicked Properties and saw that Read-only check box is checked under Attributes.

I un-checked Read only check box and cliked Apply and clicked OK on the new popup that is shown.

I went back to Visual Studio and build my solution which was giving me error messages.

Voilaa.. This time it build successfully without errors.

I donot know whether this is perfect but I did this to solve my issue.

score 3 · Answer 6 · answered Feb 13 '18 at 16:32

3

To work around this problem I had to remove the "ReadOnly" flag on the source directory

Then in the build definition set Clean Workspace

to None

answered Feb 13 '18 at 16:32

rupweb

3,052
1
30
57

This quick fix worked for me. Procedures described in other answers may be necessary. This work around is worth a try. Your mileage may vary. – JohnH Dec 15 '21 at 14:57

score 1 · Answer 7 · answered Jul 17 '15 at 13:47

Like Ziggler, I solved this problem with building a project by removing the 'read only' property of the bin folder in my project. It is only happening to XML files stored in a /packages/ directory that is common to the solution that contains this project. The 'bin' folder is not checked into source control. I am still stumped as to the root cause of the problem.

score 1 · Answer 8 · answered Sep 24 '15 at 05:15

I found the same problem which occurred after the build tried to overwrite files in the "Working Directory" it had created in a previous attempt to build. (set in the Agent)

I resolved this by manually deleting the output folder it created (in my case [Working Directory]\Binaries) before attempting the build.

This can be done automatically by changing the Build Definition. Under Process---2.Basic---Clean Workspace set this to the Outputs option

score 1 · Answer 9 · answered Mar 20 '17 at 15:37

Here's a variation of this problem which I had to deal with:

I couldn't figure out why my build kept failing on an "Access to the path is denied" error, even though I had added things like /p:BuildInParallel=false and /p:OverwriteReadOnlyFiles=true to the MSBuild Arguments of my XAML build. The cause turned out to be a "Post-build event command line" in my Project's properties.

After changing

%WinDir%\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe[SNIP] 
/P:Configuration=$(ConfigurationName);[SNIP] 
;AutoParameterizationWebConfigConnectionStrings=false

to

%WinDir%\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe[SNIP] 
/P:Configuration=$(ConfigurationName);[SNIP]
;AutoParameterizationWebConfigConnectionStrings=false;OverwriteReadOnlyFiles=true

the error went away.

score 0 · Answer 10 · edited Jun 14 '16 at 21:42

0

One possible cause is if you have the bin or obj folders for class libraries checked-in into TFS. Deleting the bin or obj folders of the projects from TFS will resolve this issue if that is the case.

edited Jun 14 '16 at 21:42

DVK

2,726
1
17
20

answered Jan 15 '13 at 08:28

Jasmin Sinanovic

11

1

This can, and may, happen even without checking-in obj folders. – Tanveer Badar Sep 17 '13 at 04:58

score 0 · Answer 11 · edited May 23 '17 at 11:47

I was having this problem and chose to ignore it because I didn't want to sacrifice build performance for the sake of getting rid of some benign error messages by NuGet. However, I seem to have stumbled across a solution while trying to solve another problem, and I think it is related. I think the order of fetching of NuGet packages is related to the build order of projects in the solution. So if this has somehow become disjointed, then NuGet may be the first casualty before you run into build errors where you start getting "Metadata file 'XXX.dll' could not be found" errors which annoyingly require you to build again until the build succeeds (as described here).

So, I believe the solution is to follow the steps described in the accepted answer to the aforementioned question. Or, follow the more comprehensive steps in one of the alternative answers. In other words, disable building of all projects, restart VS, then re-enable building of all projects. This will (normally) resolve build order. And that should hopefully resolve the NuGet issue. Please let me know if this fixes it for anyone.

score 0 · Answer 12 · answered Sep 27 '17 at 15:16

I had this issue, with TFS 2015. It turned out to be because the build Agent was running under the default (NETWORK SERVICE) credentials, which didn't have write permissions on the target folder. Once I'd removed the Agent and reinstalled it with credentials it worked. It did have me trawling through the logs for a while, checking and unchecking the multi-proc box and even restarting the build server in my hunt. Check the obvious stuff first...

score 0 · Answer 13 · answered Jul 19 '18 at 08:33

0

For me, it was that the build agent wasn't started in an administrator powershell.

answered Jul 19 '18 at 08:33

andras

3,305
5
30
45

score 0 · Answer 14 · answered May 11 '21 at 06:14

0

MSBuild arguments:- /tv:14.0 /t:Rebuild /m:1 /p:RunCodeAnalysis=false /p:TreatWarningsAsErrors=false /p:OverwriteReadOnlyFiles=true /p:BuildInParallel=false /p:AllowedReferenceRelatedFileExtensions=none

strong text

Set false to Clean workspace
Go to build agent and remove read only from mapped folder.

answered May 11 '21 at 06:14

Vivek Raj

353
3
3

That text is indeed strong. – ProgrammingLlama Jan 26 '22 at 08:31

score -1 · Answer 15 · edited Oct 28 '14 at 16:09

as a lot of people have already stated before, this happens when building projects in parallel. Project A and B both referencing 3rd Party Library C (Copy Local) will cause this when they are build at the same Time - side by side.

The real problem is, that TFS Build 2012 and below are configured that when building a solution, the whole output of the solution is copied to a single folder. Thats where the pains of parallel builds are having their origins.

Since TFS 2013 you can easily solve this by setting the "Output location" in the build definition to "PerProject". This forces the build services to behave like a local msbuild run where the setings regarding the output locations are read from the corresponding project files. So the output is written to the bin folders under each project.

For TFS 2012 and below this article (+linked articles) will help you getting the same result as with TFS 2013:

http://blog.stangroome.com/2012/05/10/override-the-tfs-team-build-outdir-property-net-4-5/

I tried this solution on our TFS 2013, but it did not solve the problem. — Nathan A, Oct 28 '14 at 16:15
This does solve the problem, provide me the log containing the error after the modification. And I'll tell you the real problem. — Scordo, Nov 05 '14 at 08:49

score -2 · Answer 16 · answered Nov 06 '14 at 03:14

-2

I resolved a very similar issue by closing all open instances of Visual Studio, re-opening the solution and building it again.

answered Nov 06 '14 at 03:14

Chris Halcrow

28,994
18
176
206

2

Hmmm ... the question is about TFS builds. Not Visual Studio. How is this helpful? – Dan Esparza Nov 11 '14 at 20:27
@DanEsparza Might be applicable if the VS instances are on the same machine as the TFS build agent. – Shiv Oct 23 '17 at 01:08

TFS 2012 Build "Access to Path Denied"

16 Answers16

Linked