TFS 2012 빌드 "경로에 대한 액세스가 거부 됨"

TFS 2012 빌드 "경로에 대한 액세스가 거부 됨"

---

TFS 2012 Build를 사용하고 있으며 오류가 발생했습니다.

경로에 대한 액세스가 거부되었습니다.

빌드중인 솔루션에는 약 15 개의 프로젝트가 포함되어 있으며 그중 다수가 Castle.Components.Validator.2.5.0 어셈블리를 사용하고 있습니다.

TFS Build Access Denied 오류에 대해 이야기하는 다른 게시물을 보았지만 일반적으로 동시 빌드 실행을 언급합니다. 이 경우 한 번에 하나의 빌드 만 실행됩니다. 또한 서버가 다시 시작되거나 빌드가 한동안 실행되지 않은 경우 오류가 발생합니다.

빌드가 실행되고 실패하면 다음 빌드가 성공하고 빌드가 한동안 실행되지 않았거나 서버가 다시 시작될 때까지 각 빌드가 다시 성공합니다. 이 문제를 피할 수는 있지만 수동적 인 두통입니다.

다음은 오류입니다.

C : \ WINDOWS \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Microsoft.Common.targets (3513) : "D : \ Builds \ 12 \ Foo \ Check-In Build \ Sources \ packages \ Castle.Components 파일을 복사 할 수 없습니다. .Validator.2.5.0 \ lib \ NET40 \ Castle.Components.Validator.dll "을"D : \ Builds \ 12 \ Foo \ Check-In Build \ Binaries \ Castle.Components.Validator.dll "로 변경합니다.

경로 'D : \ Builds \ 12 \ Foo \ Check-In Build \ Binaries \ Castle.Components.Validator.dll'에 대한 액세스가 거부되었습니다.

로그 파일을 보면 빌드가 파일 복사를 두 번 시도하고 있음을 알 수 있습니다. 첫 번째 파일에 잠금이 있기 때문에 두 번째 파일이 실패하여 빌드가 실패합니다. 다음은 무슨 일이 일어나고 있는지 보여주는 로그 파일의 일부입니다.

2> _CopyFilesMarkedCopyLocal : "D : \ Builds \ 12 \ Foo \ Check-In Build \ Sources \ packages \ Castle.Components.Validator.2.5.0 \ lib \ NET40 \ Castle.Components.Validator.dll"에서 "로 파일 복사 D : \ Builds \ 12 \ Foo \ Check-In Build \ Binaries \ Castle.Components.Validator.dll ".

5> _CopyFilesMarkedCopyLocal : "D : \ Builds \ 12 \ Foo \ Check-In Build \ Sources \ packages \ Castle.Components.Validator.2.5.0 \ lib \ NET40 \ Castle.Components.Validator.dll"에서 "로 파일 복사 D : \ Builds \ 12 \ Foo \ Check-In Build \ Binaries \ Castle.Components.Validator.dll ".

2> _CopyFilesMarkedCopyLocal : "D : \ Builds \ 12 \ Foo \ Check-In Build \ Sources \ packages \ MvcContrib.Mvc3.FluentHtml-ci.3.0.96.0 \ lib \ MvcContrib.FluentHtml.dll"에서 "D : \ Builds \ 12 \ Foo \ Check-In Build \ Binaries \ MvcContrib.FluentHtml.dll "입니다. "D : \ Builds \ 12 \ Foo \ Check-In Build \ Sources \ packages \ RhinoMocks.3.6 \ lib \ Rhino.Mocks.dll"에서 "D : \ Builds \ 12 \ Foo \ Check-In Build \로 파일 복사 Binaries \ Rhino.Mocks.dll "입니다.

이 문제를 해결하는 방법에 대한 도움을 주시면 감사하겠습니다.

---

동일한 파일을 복사하는 두 개의 프로젝트가있는 것 같습니다. 타이밍에 따라 때때로 동시에 발생하여 오류가 발생합니다. 소스 프로젝트를 찾으려면 노드 ID를 다시 추적해야합니다. 자세한 내용과 추적 할 수있는 코드는 http://blogs.msdn.com/b/buckh/archive/2012/01/21/a-tool-to-find-duplicate-copies-in-a-build.aspx 를 참조하십시오. 당신을 위해 아래로.

---

다른 사람들이 언급했듯이 이것은 공통 대상 디렉토리로 다중 스레드 빌드를 수행 할 때 발생하며 파일 복사 작업은 다른 프로젝트에 대해 실행중인 복사 작업과 동시에 충돌이 발생합니다.

일반적으로 이로 인해 "다른 프로세스에서 사용하는 파일"예외 (파일 복사 작업에 의해 처리되고 다시 시도 됨)가 발생하지만 파일 작업으로 인해 대신 "액세스가 거부되었습니다"예외가 발생하는 경우가 있습니다. (아직도 이유를 모르겠습니다)

일부는 "중복을 해결"해야한다고 제안하지만 모든 프로젝트가 log4net과 같은 라이브러리를 직접 참조해야하는 경우에는 실현 가능하다고 생각하지 않습니다.

분명히이 문제를 방지하는 한 가지 방법은 /p:BuildInParallel=false또는 /m:1또는 또는 /maxcpucount:1(또는 인수를 완전히 생략하여) msbuild를 명시 적으로 실행 하여 단일 스레드 모드를 강제하는 것입니다.

그러나 TFS 2013 에서 기본 빌드 템플릿은 항상 /mmsbuild에 자동으로 전달 (모든 코어 사용)하여 수동으로 전달할 수있는 단일 스레드 설정을 자동으로 재정의합니다. (내 실험 및 진단 로그 검사에 의해 결정됨)

내가 시도한 또 다른 해결 방법은 /p:AllowedReferenceRelatedFileExtensions=nonemsbuild 에 수동으로 전달 하여 모든 pdb 및 xml 파일이 참조 된 라이브러리에서 복사되지 않도록하는 것입니다. (한동안이 문제가있는 xml 파일 만 본 적이 있습니다.)하지만 그 후 log4net.dll에 계속 문제가 발생했습니다.

내가 사용한 궁극적 인 해결 방법은 다음에 대한 소스 코드를 디 컴파일하여 발견 한 것입니다 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]);
}

오류 -2147024891 (0x80070005 액세스가 거부 됨)이 발생하면 복사 작업은 특수 변수를 확인하여 재 시도해야하는지 확인합니다. 이 값은 환경 변수를 통해 설정됩니다.

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

환경 변수 MSBUILDALWAYSRETRY = 1을 설정하고 빌드 서버를 다시 시작한 후 문제가 해결되었습니다. 그리고 나는 또한 주기적으로 설정합니다 (빌드 대신 단지 우연히 성공), 효과를 가지고 것을 증명, 빌드 로그에 경고로 "... ERROR_ACCESS_DENIED에 다시 시도"를보고 시작했다.

(이 환경 변수는 잘 문서화되어 있지 않으므로 적절하게 사용하십시오.)

업데이트 : 분명히 TFS 2015는 더 이상 (레거시 / XAML 빌드 정의에서도) 사용자 /m:1를 재정의하지 않으므로 다시 유효한 수정 /m을해야 /m:1합니다.

---

Buck Hodges와 Nimblejoe가 올바르게 말했듯이 이는 대부분 TFS가 기본적으로 프로젝트를 빌드하기 위해 여러 MSBuild 프로세스를 실행하기 때문입니다.

Process- > 3. Advanced-> MSBuild Arguments 의 빌드 정의에서 MSBuild 인수 / p : BuildInParallel = false 를 추가하여 재정의 할 수 있습니다 .

---

빌드 에이전트의 폴더가 열려있는 경우에도 발생할 수 있습니다.

---

나도 같은 문제가 있었다. 경로에 대한 액세스가 거부 되었기 때문에 복사 할 수 없다는 오류 메시지가 나타납니다. 제 경우에는 모든 dll 및 xml 파일 등이 D : \ TFS \ Example \ Bin \ Debug 폴더에 있습니다.

Bin 폴더를 마우스 오른쪽 버튼으로 클릭하고 속성을 클릭 한 결과 속성에서 읽기 전용 확인란이 선택되어있는 것을 확인했습니다.

읽기 전용 확인란의 선택을 취소하고 적용을 클릭하고 표시되는 새 팝업에서 확인을 클릭했습니다.

Visual Studio로 돌아가서 오류 메시지를 표시하는 솔루션을 빌드했습니다.

Voilaa .. 이번에는 오류없이 성공적으로 빌드되었습니다.

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

---

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

---

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.

---

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

---

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.

---

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.

---

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.

---

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...

---

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

---

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 resolved a very similar issue by closing all open instances of Visual Studio, re-opening the solution and building it again.

참고URL : https://stackoverflow.com/questions/12905693/tfs-2012-build-access-to-path-denied