Question

我正在使用TFS 2012构建并运行错误

拒绝访问路径

正在构建的解决方案包含大约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“to”D：\ Builds \ 12 \ Foo \ Check-In Build \ Binaries \ Castle.Components.Validator.dll“。< / p>
访问路径'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＆gt; _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＆gt; _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 \”二进制\ Rhino.Mocks.dll”。

如何解决这个问题的任何帮助将不胜感激。

Answer 1

正如其他人所提到的，当使用公共目标目录执行多线程构建并且文件复制任务碰巧遇到与为不同项目运行的复制任务同时发生冲突时，会发生这种情况。

通常这会导致“另一个进程使用的文件”异常（由文件复制任务处理和重试），但有时文件操作会导致“访问被拒绝”异常。（我还不确定为什么）

有人建议您应该“解决重复问题”，但我不认为这对于所有项目都需要直接引用像log4net这样的库的情况是可行的。

显然，防止此问题的一种方法是使用/p:BuildInParallel=false或/m:1或/maxcpucount:1显式运行msbuild（或完全省略参数）以强制使用单线程模式。

但是，在TFS 2013 中，默认构建模板会自动将/m（使用所有核心）传递给msbuild，它会静默覆盖您可以手动传入的任何单线程设置。（由我自己的实验和检查诊断日志确定）

我尝试的另一种解决方法是手动将/p:AllowedReferenceRelatedFileExtensions=none传递给msbuild，这会阻止从引用的库中复制所有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不再覆盖/m:1 /m（即使是遗留/ XAML构建定义），这应该使/m:1有效再次修复。

Answer 2

看起来有两个项目正在复制同一个文件。根据时间安排，它们有时会同时发生，从而导致失败。您必须追溯节点ID以查找源项目。有关详细信息和可能会为您追踪的详细信息，请参阅http://blogs.msdn.com/b/buckh/archive/2012/01/21/a-tool-to-find-duplicate-copies-in-a-build.aspx。

Answer 3

正如Buck Hodges和Nimblejoe所说，这主要是因为TFS默认运行多个MSBuild进程来构建你的项目。

您可以在 Process - ＆gt;中的构建定义中覆盖它。 3.高级 - ＆gt; MSBuild Arguments 通过添加MSBuild参数 / p：BuildInParallel = false

Answer 4

如果您打开了构建代理的文件夹，也会发生这种情况。

Answer 5

我也有同样的问题。我收到的错误消息与无法复制相关，因为访问路径被拒绝。在我的情况下，所有我的dll和xml文件等都放在 D：\ TFS \ Example \ Bin \ Debug文件夹。

我右键单击Bin文件夹并单击属性，并在“属性”下看到“只读”复选框。

我取消选中了“只读”复选框，并在显示的新弹出窗口中单击“确定”并单击“确定”。

我回到Visual Studio并构建我的解决方案，它给了我错误消息。

Voilaa ..这次成功构建没有错误。

我不知道这是否完美，但我这样做是为了解决我的问题。

Answer 6

要解决这个问题，我不得不删除＆＃34; ReadOnly＆＃34;源目录上的标志

然后在构建定义中设置Clean Workspace

到无

Answer 7

与Ziggler一样，我通过删除项目中bin文件夹的“只读”属性来解决此问题。它只发生在存储在/ packages /目录中的XML文件中，该文件对于包含此项目的解决方案是通用的。 'bin'文件夹未检入源代码管理中。我仍然难以解决问题的根本原因。

Answer 8

我发现构建试图覆盖＆＃34;工作目录＆＃34;中的文件后发生了同样的问题。它是在之前的构建尝试中创建的。（在代理中设置）

我通过在尝试构建之前手动删除它创建的输出文件夹（在我的情况下是[Working Directory] \ Binaries）来解决这个问题。

这可以通过更改构建定义自动完成。在流程 --- 2.Basic --- 清洁工作区下将其设置为 输出 < / strong>选项

Answer 9

以下是我必须处理的这个问题的变体：

我无法弄清楚为什么我的构建在＃34上失败了;对路径的访问被拒绝＆＃34;错误，即使我已将/p:BuildInParallel=false和/p:OverwriteReadOnlyFiles=true之类的内容添加到我的XAML构建的MSBuild参数中。原因是＆＃34; 构建后事件命令行＆＃34;在我的项目属性中。

更改后

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

到

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

错误消失了。

Answer 10

一个可能的原因是，如果您在TFS中签入了类库的bin或obj个文件夹。如果是这种情况，从TFS中删除项目的bin或obj文件夹将解决此问题。

Answer 11

我遇到了这个问题，并选择忽略它，因为我不想为了摆脱NuGet的一些良性错误消息而牺牲构建性能。但是，在尝试解决另一个问题时，我似乎偶然发现了一个解决方案，我认为这是相关的。我认为获取NuGet包的顺序与解决方案中项目的构建顺序有关。因此，如果这种情况以某种方式脱节，那么NuGet可能是您遇到构建错误之前的第一个受害者，您可能会开始获取＆＃34;元数据文件＆＃39; XXX.dll＆＃39;无法找到＆＃34;在构建成功之前烦人地要求你再次构建的错误（如here所述）。

因此，我认为解决方案是遵循上述问题的接受答案中描述的步骤。或者，按照one of the alternative answers中更全面的步骤操作。换句话说，禁用所有项目的构建，重新启动VS，然后重新启用所有项目的构建。这将（通常）解析构建顺序。这应该有希望解决NuGet问题。如果这样可以解决任何问题，请告诉我。

Answer 12

我有这个问题，TFS 2015。结果是因为构建代理程序在默认（NETWORK SERVICE）凭据下运行，该凭据对目标文件夹没有写入权限。一旦我删除了代理并使用凭据重新安装它就可以了。它确实让我在日志中拖了一段时间，检查并取消选中多进程盒，甚至在我的搜索中重新启动构建服务器。先检查明显的东西......

Answer 13

对我来说，构建代理不是在管理员Powershell中启动的。

Answer 14

MSBuild 参数：- /tv:14.0 /t:Rebuild /m:1 /p:RunCodeAnalysis=false /p:TreatWarningsAsErrors=false /p:OverwriteReadOnlyFiles=true /p:BuildInParallel=false /p:AllowedReferenceRelatedFileExtensions=none< /p>

强文本

设置 false 为清理工作区
转到构建代理并从映射文件夹中删除只读。

Answer 15

很多人之前已经说过，这是在并行构建项目时发生的。项目A和B都引用第三方库C（复制本地），当它们在同一时间并排构建时会产生这种情况。

真正的问题是，配置TFS Build 2012及更低版本，在构建解决方案时，解决方案的整个输出将复制到单个文件夹。这就是并行构建的痛苦源于它们的原因。

自TFS 2013起，您可以通过设置＆＃34;输出位置＆＃34;轻松解决此问题。在构建定义中＆＃34; PerProject＆＃34;。这会强制构建服务的行为类似于本地msbuild运行，其中从相应的项目文件中读取有关输出位置的设置。因此输出将写入每个项目下的bin文件夹。

对于TFS 2012及以下文章（+链接文章）将帮助您获得与TFS 2013相同的结果：

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

Answer 16

我通过关闭所有打开的Visual Studio实例，重新打开解决方案并再次构建它来解决了一个非常类似的问题。

TFS 2012构建“拒绝访问路径”

16 个答案: