wake-up-neo.com

TFS 2012 Build "Zugriff auf Pfad verweigert"

Ich verwende TFS 2012 Build und habe einen Fehler

Zugriff auf den Pfad wird verweigert

Die zu erstellende Lösung enthält etwa 15 Projekte, von denen eine Anzahl die Assembly Castle.Components.Validator.2.5.0 verwendet.

Ich habe andere Beiträge gesehen, die über die TFS Build Access Denied-Fehler sprechen, aber sie beziehen sich im Allgemeinen auf das gleichzeitige Ausführen von Builds. In diesem Fall wird jeweils nur ein Build ausgeführt. Der Fehler tritt auch auf, wenn der Server neu gestartet wird oder der Build für einige Zeit nicht ausgeführt wurde.

Sobald ein Build ausgeführt wurde und fehlgeschlagen ist, ist der nächste erfolgreich, und jeder nachfolgende Build ist erneut erfolgreich, bis der Build eine Zeit lang nicht ausgeführt wurde oder der Server neu gestartet wird. Obwohl wir das umgehen können, ist es ein manueller Kopfschmerz.

Hier ist der Fehler:

C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets (3513): Datei "D:\Builds\12\Foo\Check-In Build\Quellen\Pakete\Castle.Components" kann nicht kopiert werden .Validator.2.5.0\lib\NET40\Castle.Components.Validator.dll "bis" D:\Builds\12\Foo\Check-In Build\Binaries\Castle.Components.Validator.dll ".

Zugriff auf den Pfad 'D:\Builds\12\Foo\Check-In Build\Binaries\Castle.Components.Validator.dll' wird verweigert.

Wenn Sie die Protokolldatei betrachten, können Sie feststellen, dass der Build die Datei zweimal zu kopieren versucht. Da die erste Datei eine Sperre für die Datei hat, schlägt die zweite Datei fehl, und der Build schlägt fehl. Hier ist ein Ausschnitt der Protokolldatei, der zeigt, was passiert:

2> _CopyFilesMarkedCopyLocal: Kopieren der Datei von "D:\Builds\12\Foo\Check-In Build\Sources\packages\Castle.Components.Validator.2.5.0\lib\NET40\Castle.Components.Validator.dll" nach "D:\Builds"\12\Foo\Check-In Build\Binaries\Castle.Components.Validator.dll ". 

5> _CopyFilesMarkedCopyLocal: Kopieren der Datei von "D:\Builds\12\Foo\Check-In Build\Sources\packages\Castle.Components.Validator.2.5.0\lib\NET40\Castle.Components.Validator.dll" nach "D:\Builds"\12\Foo\Check-In Build\Binaries\Castle.Components.Validator.dll ". 

2> _CopyFilesMarkedCopyLocal: Datei aus "D:\Builds\12\Foo\Check-In Build\Sources\packages\MvcContrib.Mvc3.FluentHtml-ci.3.0.96.0\lib\MvcContrib.FluentHtml.dll" nach "D:\Builds\12" kopieren\Foo\Check-In Build\Binaries\MvcContrib.FluentHtml.dll ". Datei aus "D:\Builds\12\Foo\Check-In Build\Sources\packages\RhinoMocks.3.6\lib\Rhino.Mocks.dll" nach "D:\Builds\12\Foo\Check-In Build \" kopieren Binaries\Rhino.Mocks.dll ".

Jede Hilfe zur Behebung dieses Problems wäre sehr dankbar.

64
Nimblejoe

Anscheinend gibt es zwei Projekte, die dieselbe Datei kopieren. Abhängig vom zeitlichen Ablauf finden sie manchmal gleichzeitig statt und führen zum Ausfall. Sie müssen die Knoten-ID zurückverfolgen, um das Quellprojekt zu finden. Siehe http://blogs.msdn.com/b/buckh/archive/2012/01/21/a-tool-to-find-duplicate-copies-in-a-build.aspx für weitere Informationen und Code, der es für Sie aufspüren kann. 

40
Buck Hodges

Wie bereits erwähnt, geschieht dies, wenn Multithread-Builds mit einem gemeinsamen Zielverzeichnis ausgeführt werden und bei der Dateikopieraufgabe ein gleichzeitiger Konflikt mit einer Kopieraufgabe auftritt, die für ein anderes Projekt ausgeführt wird. 

Normalerweise sollte dies zu einer Ausnahme "Datei, die von einem anderen Prozess verwendet wird" (die von der Dateikopieraufgabe behandelt und wiederholt wird) führen. Manchmal führt die Dateioperation jedoch zu einer Ausnahme "Zugriff wird verweigert". (Ich bin immer noch nicht sicher warum)

Einige meinen, Sie sollten "die Duplizierung lösen", aber ich halte das nicht für machbar, wenn alle Projekte direkt auf eine Bibliothek wie log4net verweisen müssen.

Offensichtlich besteht eine Möglichkeit, das Problem zu verhindern, indem Sie msbuild explizit mit /p:BuildInParallel=false oder /m:1 oder /maxcpucount:1 ausführen (oder das Argument vollständig auslassen), um den Single-Thread-Modus zu erzwingen. 

In TFS 2013 übergibt die Standard-Buildvorlage jedoch automatisch /m (alle Kerne verwenden) an msbuild, wodurch jede Einstellung von Einzelthread, die Sie manuell übergeben können, unbemerkt überschrieben wird )

Eine andere Problemumgehung, die ich versucht habe, war, /p:AllowedReferenceRelatedFileExtensions=none manuell an msbuild zu übergeben, wodurch verhindert wird, dass alle pdb- und xml-Dateien aus referenzierten Bibliotheken kopiert werden. (Seit einiger Zeit habe ich immer nur XML-Dateien mit diesem Problem gesehen.) Aber dann hatte ich immer Probleme mit log4net.dll.

Die ultimative Problemumgehung, die ich verwendete, war eine, die ich durch Dekompilieren des Quellcodes für Microsoft.Build.Tasks.Copy entdeckte:

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

Wenn der Fehler -2147024891 (0x80070005 Zugriff verweigert) auftritt, prüft der Kopiertask eine spezielle Variable, um zu sehen, ob er es erneut versuchen soll. Dieser Wert wird über eine Umgebungsvariable eingestellt:

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

Nachdem Sie die Umgebungsvariable MSBUILDALWAYSRETRY = 1 festgelegt haben (und den Build-Server erneut gestartet haben), ist das Problem behoben. Und Ich habe auch regelmäßig begonnen, "Retrying on ERROR_ACCESS_DENIED ..." als Warnungen in den Build-Protokollen zu sehen, um zu beweisen, dass die Einstellung wirksam wurde (anstatt dass die Builds nur zufällig erfolgreich waren).

(Beachten Sie, dass diese Umgebungsvariable nicht gut dokumentiert ist, verwenden Sie sie entsprechend.)

Update: Offensichtlich überschreibt TFS 2015 Ihren /m:1 nicht mehr mit /m (auch bei älteren/XAML-Builddefinitionen), wodurch /m:1 wieder zu einem gültigen Fix werden sollte.

48
Mike Asdf

Wie Buck Hodges und Nimblejoe zu Recht gesagt haben, liegt dies hauptsächlich daran, dass TFS standardmäßig mehrere MSBuild-Prozesse ausführt, um Ihre Projekte zu erstellen. 

Sie können es in der Builddefinition in Process -> 3 überschreiben. Erweitert -> MSBuild-Argumente, indem Sie das MSBuild-Argument/p hinzufügen: BuildInParallel = false

13
Ace

Dies kann auch passieren, wenn der Ordner eines Build-Agenten geöffnet ist.

11
StingyJack

Ich hatte auch das gleiche Problem. Ich habe Fehlermeldungen erhalten, die nicht kopiert werden können, da der Zugriff auf den Pfad verweigert wurde. In meinem Fall befinden sich alle meine DLL- und XML-Dateien usw. unter D:\TFS\Example\Bin\Debug-Ordner. 

Ich habe mit der rechten Maustaste auf den Ordner Bin geklickt und auf Eigenschaften geklickt. Das Kontrollkästchen Schreibgeschützt ist unter Attribute aktiviert.

Ich habe das Kontrollkästchen Schreibgeschützt deaktiviert und auf Anwenden geklickt und in dem angezeigten neuen Popup auf OK geklickt.

Ich ging zurück zu Visual Studio und baute meine Lösung, die mir Fehlermeldungen gab. 

Voilaa .. Diesmal erfolgreich gebaut ohne Fehler.

Ich weiß nicht, ob dies perfekt ist, aber ich habe dies getan, um mein Problem zu lösen.

6
Ziggler

Um dieses Problem zu umgehen, musste ich das Flag "ReadOnly" im Quellverzeichnis entfernen

 readonly

Dann legen Sie in der Builddefinition Clean Workspace fest

 workspace

zu Keine

 enter image description here

2
rupweb

Wie Ziggler löste ich dieses Problem beim Erstellen eines Projekts, indem ich die Eigenschaft des schreibgeschützten Ordners "bin" in meinem Projekt entfernte. Dies geschieht nur bei XML-Dateien, die in einem Verzeichnis/packages/gespeichert sind, das in der Projektmappe enthalten ist, die dieses Projekt enthält. Der Ordner 'bin' wird nicht in die Quellcodeverwaltung eingecheckt. Ich bin immer noch über die Ursache des Problems verblüfft. 

1
rpstex

Hier ist eine Variation dieses Problems, mit der ich mich befassen musste: 

Ich konnte nicht herausfinden, warum bei meinem Build der Fehler "Zugriff auf Pfad wurde verweigert" fehlschlug, obwohl ich den MSBuild-Argumenten meines XAML-Builds Dinge wie /p:BuildInParallel=false und /p:OverwriteReadOnlyFiles=true hinzugefügt hatte. Die Ursache war eine " Post-build-Ereignisbefehlszeile " in den Eigenschaften meines Projekts.

Nach dem Wechsel

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

zu

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

der Fehler ging weg.

1

Ich fand das gleiche Problem, das nach dem Versuch des Builds auftrat, Dateien im "Arbeitsverzeichnis" zu überschreiben, das er bei einem früheren Build-Versuch erstellt hatte. (im Agent einstellen)

Ich habe das Problem behoben, indem Sie den erstellten Ausgabeordner (in meinem Fall [Arbeitsverzeichnis] ​​\ Binaries) vor dem Build manuell gelöscht haben.

Dies kann automatisch durch Ändern der Build-Definition erfolgen. Stellen Sie unter Process --- 2.Basic --- Clean Workspace die OptionOutputsein

1
Cyborg

Eine mögliche Ursache ist, wenn Sie die Ordner bin oder obj für Klassenbibliotheken in TFS eingecheckt haben. Wenn Sie die Ordner bin oder obj der Projekte aus TFS löschen, wird dieses Problem behoben, wenn dies der Fall ist.

0

Ich hatte dieses Problem mit TFS 2015. Es stellte sich heraus, dass der Build-Agent mit den Standardberechtigungen (NETWORK SERVICE) ausgeführt wurde, die keine Schreibberechtigung für den Zielordner hatten. d entfernte den Agenten und installierte ihn erneut mit den Berechtigungsnachweisen, die funktionierten .. __ Ich musste die Protokolle eine Weile durchforsten, das Multi-Proc-Kontrollkästchen aktivieren und deaktivieren und sogar den Build-Server in meiner Jagd starten offensichtliches Zeug zuerst ...

0
Detail

Für mich war es, dass der Build-Agent nicht in einer Administrator-Powershell gestartet wurde.

0
andras

Ich hatte dieses Problem und entschied mich, es zu ignorieren, weil ich die Build-Leistung nicht opfern wollte, um ein paar gutartige Fehlermeldungen von NuGet loszuwerden. Anscheinend bin ich beim Versuch, ein anderes Problem zu lösen, auf eine Lösung gestoßen, und ich denke, es hängt damit zusammen. Ich denke, die Reihenfolge beim Abrufen von NuGet-Paketen hängt von der Reihenfolge der Erstellung von Projekten in der Lösung ab. Wenn dies irgendwie unzusammenhängend geworden ist, kann NuGet der erste Verlust sein, bevor Sie Build-Fehler erhalten, bei denen Sie "Metadatendatei 'XXX.dll' konnten nicht gefunden werden" (wie beschrieben hier ).

Ich glaube, die Lösung besteht darin, die in der akzeptierten Antwort auf die oben genannte Frage beschriebenen Schritte zu befolgen. Oder folgen Sie den umfassenderen Schritten in einer der alternativen Antworten . Deaktivieren Sie also das Erstellen aller Projekte, starten Sie VS erneut und aktivieren Sie dann das Erstellen aller Projekte erneut. Dadurch wird (normalerweise) die Build-Reihenfolge aufgelöst. Und das sollte hoffentlich das NuGet-Problem lösen. Bitte lassen Sie mich wissen, ob dies für jeden die Ursache ist.

0
Neo