TFS 2012ビルド「パスへのアクセスが拒否されました」
TFS 2012 Buildを使用していますが、エラーが発生しました
パスへのアクセスが拒否されました
構築中のソリューションには、Castle.Components.Validator.2.5.0アセンブリを使用しているプロジェクトが約15個含まれています。
TFSビルドアクセスの拒否エラーについて説明している他の投稿を見ましたが、それらは一般に同時ビルドの実行について言及しています。この場合、一度に実行されるビルドは1つだけです。また、サーバーが再起動されるか、ビルドがしばらく実行されなかったときにエラーが発生します。
ビルドが実行されて失敗すると、次のビルドが成功し、ビルドがしばらく実行されなくなるか、サーバーが再起動されるまで、それぞれが再び成功します。これを回避することはできますが、それは手動の頭痛です。
エラーは次のとおりです。
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回コピーしようとしていることがわかります。最初のものはファイルをロックしているため、2番目のものは失敗し、ビルドは失敗します。以下は、何が起こっているかを示すログファイルのスニペットです。
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」にファイルをコピー\ 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 "。
これを修正する方法についてのヘルプは大歓迎です。
同じファイルをコピーする2つのプロジェクトがあるようです。タイミングによっては、それらが同時に発生し、障害が発生することがあります。ソースプロジェクトを見つけるには、ノードIDをトレースバックする必要があります。 http://blogs.msdn.com/b/buckh/archive/2012/01/21/a-tool-to-find-duplicate-copies-in-a-build.aspx を参照してくださいそれを追跡するための詳細とコード。
他の人が述べたように、これは共通の宛先ディレクトリでマルチスレッドビルドを実行するときに発生し、ファイルコピータスクは別のプロジェクトで実行されているコピータスクとの同時競合に遭遇します。
通常、これは「ファイルが別のプロセスによって使用される」例外（ファイルコピータスクによって処理および再試行される）になるはずですが、ファイル操作の結果として「アクセスが拒否されました」例外が発生する場合があります。 （理由はまだわかりません）
「重複を解決する」べきだと言う人もいますが、すべてのプロジェクトがlog4netのようなライブラリを直接参照する必要がある場合には実行可能であるとは思いません。
明らかに、この問題を防ぐ1つの方法は、msbuildを_/p:BuildInParallel=false_または_/m:1_または_/maxcpucount:1_で明示的に実行する（または引数を完全に省略する）ことで、シングルスレッドモードを強制することです。
ただし、TFS 201の場合、デフォルトのビルドテンプレートは常に_/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を設定（およびビルドサーバーを再起動）した後、問題はなくなりました。 Andまた、ビルドログの警告として定期的に「ERROR_ACCESS_DENIED ...で再試行」を確認し、設定が有効になっていることを証明しました。ビルドは偶然に成功するだけです）。
（この環境変数は十分に文書化されていないことに注意してください。必要に応じて使用してください。）
更新：どうやらTFS 2015は_/m:1_を_/m_で上書きしなくなりました（レガシー/ XAMLビルド定義であっても）。これにより_/m:1_が再び有効な修正になります。
Buck HodgesとNimblejoeが正しく言ったように、これは主にプロジェクトをビルドするためにデフォルトで複数のMSBuildプロセスを実行するTFSによるものです。
ビルド定義でProcess-> 3. Advanced-> MSBuild Argumentsでオーバーライドできます。MSBuild引数/ p：BuildInParallel = false
これは、ビルドエージェントのフォルダーを開いている場合にも発生する可能性があります。
私も同じ問題を抱えていました。パスへのアクセスが拒否されたため、コピーできないことに関連するエラーメッセージが表示されました。私の場合、dllおよびxmlファイルなどはすべてD：\ TFS\Example\Bin\Debugフォルダーに配置されています。
Binフォルダーを右クリックして[プロパティ]をクリックすると、[属性]で[読み取り専用]チェックボックスがオンになっていることがわかりました。
[読み取り専用]チェックボックスをオフにして[適用]を選択し、表示される新しいポップアップで[OK]をクリックしました。
Visual Studioに戻り、エラーメッセージが表示されるソリューションを構築しました。
Voilaa ..今回はエラーなしで正常にビルドされます。
これが完璧かどうかはわかりませんが、私の問題を解決するためにこれを行いました。
この問題を回避するには、ソースディレクトリの「ReadOnly」フラグを削除する必要がありました。
次に、ビルド定義でクリーンワークスペースを設定します
toなし
Zigglerと同様に、プロジェクトのbinフォルダーの「読み取り専用」プロパティを削除することで、プロジェクトの構築に関するこの問題を解決しました。このプロジェクトを含むソリューションに共通の/ packages /ディレクトリに保存されているXMLファイルに対してのみ発生します。 「bin」フォルダーはソース管理にチェックインされません。私はまだ問題の根本原因について困惑しています。
ここに私が対処しなければならなかったこの問題のバリエーションがあります：
/p:BuildInParallel=falseおよび/p:OverwriteReadOnlyFiles=trueをXAMLビルドのMSBuild引数に追加します。原因は、私のプロジェクトのプロパティで「ビルド後のイベントコマンドライン」であることが判明しました。
変更後
%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
エラーはなくなりました。
ビルドが以前のビルド試行で作成した「作業ディレクトリ」のファイルを上書きしようとした後に発生した同じ問題を見つけました。 （エージェントで設定）
ビルドを試みる前に、作成した出力フォルダー（私の場合は[Working Directory] \ Binaries）を手動で削除することでこれを解決しました。
これは、ビルド定義を変更することで自動的に実行できます。 プロセス ---2.Basic ---Clean WorkspaceでこれをOutputsオプション
考えられる原因の1つは、クラスライブラリ用のbinまたはobjフォルダーがTFSにチェックインされている場合です。 TFSからプロジェクトのbinまたはobjフォルダーを削除すると、この問題が解決します。
TFS 2015でこの問題が発生しました。ビルドエージェントがデフォルト（ネットワークサービス）の資格情報で実行されていたため、ターゲットフォルダーへの書き込み権限がありませんでした。エージェントを削除し、資格情報を使用して再インストールすると、機能しました。しばらくログをトロールして、マルチプロセスボックスのチェックとチェック解除を行い、ハントでビルドサーバーを再起動しました。最初に明らかなものを確認してください...
私にとっては、ビルドエージェントが管理者のPowerShellで起動されていないということでした。
私はこの問題を抱えていましたが、NuGetによる良性のエラーメッセージを取り除くためにビルドパフォーマンスを犠牲にしたくなかったため、無視することにしました。しかし、別の問題を解決しようとしているときに解決策に出くわしたようで、それは関連していると思います。 NuGetパッケージの取得順序は、ソリューション内のプロジェクトのビルド順序に関連すると思います。したがって、これが何らかの理由でバラバラになった場合、NuGetはビルドエラーが発生する前の最初の犠牲者となり、ビルドが成功するまでわずらわしくビルドする必要がある「メタデータファイル 'XXX.dll'が見つかりませんでした」というエラーが表示されます（説明されているように ここ ）。
したがって、解決策は、前述の質問に対する受け入れられた回答に記載されている手順に従うことだと思います。または、 代替回答の1つ のより包括的な手順に従ってください。つまり、すべてのプロジェクトのビルドを無効にし、VSを再起動してから、すべてのプロジェクトのビルドを再度有効にします。これにより、（通常）ビルド順序が解決されます。そして、うまくいけばNuGetの問題を解決できるはずです。これが誰かのためにそれを修正するかどうか私に知らせてください。