TFS 2012 Build "Accès au chemin refusé"
J'utilise TFS 2012 Construire et exécuter une erreur
L'accès au chemin est refusé
La solution en cours de construction contient environ 15 projets, dont certains utilisent l'assembly Castle.Components.Validator.2.5.0.
J'ai vu d'autres publications parler des erreurs TFS Build Access Denied, mais elles font généralement référence à l'exécution simultanée de versions. Dans ce cas, une seule génération est exécutée à la fois. En outre, l'erreur se produit lorsque le serveur est redémarré ou que la génération n'a pas été exécutée depuis un certain temps.
Une fois qu'une génération est exécutée et échoue, la suivante réussit et chaque tentative suivante réussit à nouveau jusqu'à ce que la génération ne soit plus exécutée ou que le serveur soit redémarré. Bien que nous puissions contourner ce problème, il s’agit d’un mal de tête manuel.
Voici l'erreur:
C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets (3513): Impossible de copier le fichier "D:\Builds\12\Foo\Enregistrement de la compilation\Sources\packages\Castle.Components .Validator.2.5.0\lib\NET40\Castle.Components.Validator.dll "à" D:\Constructions\12\Foo\Enregistrement de la compilation\Binaries\Castle.Components.Validator.dll ".
L'accès au chemin d'accès 'D:\Builds\12\Foo\Check-In Build\Binaries\Castle.Components.Validator.dll' est refusé.
En regardant le fichier journal, vous pouvez voir que la construction tente de copier le fichier deux fois. Parce que le premier a un verrou sur le fichier, le second échoue et donc la construction échoue. Voici un extrait du fichier journal qui montre ce qui se passe:
2> _CopyFilesMarkedCopyLocal: Copie du fichier de "D:\Constructions\12\Foo\Construction de construction\Sources\packages\Castle.Components.Validator.2.5.0\lib\NET40\Castle.Components.Validator.dll" dans "D:\Constructions\12\Foo\Check-In Build\Binaries\Castle.Components.Validator.dll ".
5> _CopyFilesMarkedCopyLocal: Copie du fichier de "D:\Constructions\12\Foo\Construction de construction\Sources\packages\Castle.Components.Validator.2.5.0\lib\NET40\Castle.Components.Validator.dll" dans "D:\Constructions\12\Foo\Check-In Build\Binaries\Castle.Components.Validator.dll ".
2> _CopyFilesMarkedCopyLocal: Copie du fichier à partir de "D:\Constructions\12\Foo\Enregistrement de génération\Sources\packages\MvcContrib.Mvc3.FluentHtml-ci.3.0.96.0\lib\MvcContrib.FluentHtml.dll" vers "D:\Builds\12\Foo\Check-In Build\Binaries\MvcContrib.FluentHtml.dll ". Copie du fichier de "D:\Constructions\12\Foo\Construction de contrôle\Sources\packages\RhinoMocks.3.6\lib\Rhino.Mocks.dll" dans "D:\Constructions\12\Foo\Construction de contrôle\Fichiers binaires\Rhino.Mocks.dll ".
Toute aide sur la façon de résoudre ce problème serait grandement appréciée.
Il semble que deux projets copient le même fichier. Selon le moment, ils se produisent parfois en même temps, ce qui entraîne l'échec. Vous devez retrouver l'ID de noeud pour rechercher le projet source. Voir http://blogs.msdn.com/b/buckh/archive/2012/01/21/a-tool-to-find-duplicate-copies-in-a-build.aspx pour plus de détails et code qui peut le localiser pour vous.
Comme d'autres l'ont mentionné, cela se produit lors de la création de versions multithread avec un répertoire de destination commun et lorsque la tâche de copie de fichier rencontre un conflit simultané avec une tâche de copie exécutée pour un projet différent.
Cela devrait normalement entraîner une exception "fichier utilisé par un autre processus" (qui est gérée et répétée par la tâche de copie de fichier), mais l'opération de fichier entraîne parfois une exception "Accès refusé". (Je ne sais toujours pas pourquoi)
Certains suggèrent que vous devriez "résoudre le problème de duplication", mais je ne pense pas que cela soit réalisable dans les cas où tous les projets doivent référencer directement une bibliothèque telle que log4net.
Évidemment, un moyen d'éviter le problème consiste à exécuter explicitement msbuild avec /p:BuildInParallel=false ou /m:1 ou /maxcpucount:1 (ou à omettre entièrement l'argument) pour forcer le mode mono-thread.
Cependant, dans TFS 2013 , le modèle de construction par défaut transmet toujours automatiquement /m (utilisez tous les cœurs) à msbuild, qui remplace en mode silencieux tout paramètre de thread unique que vous pouvez transmettre manuellement. (Déterminé par mes propres expériences et examen des journaux de diagnostic )
Une autre solution de contournement que j'ai tentée était de transmettre manuellement /p:AllowedReferenceRelatedFileExtensions=none à msbuild, ce qui empêche la copie de tous les fichiers pdb et xml à partir des bibliothèques référencées. (Depuis quelque temps, je n'ai jamais vu que des fichiers xml présentant ce problème.) Mais j'ai continué à avoir des problèmes avec log4net.dll.
La solution ultime que j’ai utilisée est celle que j’ai découverte en décompilant le code source pour 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]);
}
Si l'erreur -2147024891 (l'accès 0x80070005 est refusé) se produit, la tâche de copie vérifie une variable spéciale pour voir si elle doit réessayer. Cette valeur est définie via une variable d'environnement:
Copy.alwaysRetryCopy = Environment.GetEnvironmentVariable("MSBUILDALWAYSRETRY") != null;
Après avoir défini la variable d'environnement MSBUILDALWAYSRETRY = 1 (et redémarré le serveur de génération), le problème a disparu. Et J'ai aussi périodiquement commencé à voir "Réessayer sur ERROR_ACCESS_DENIED ..." comme des avertissements dans les journaux de construction, ce qui prouve que le paramètre prenait effet (au lieu des générations qui ont simplement succédé de manière fortuite).
(Notez que cette variable d’environnement n’est pas bien documentée, utilisez-la comme il convient.)
Mise à jour: Apparemment, TFS 2015 ne remplace plus votre /m:1 par /m (même sur les définitions de génération héritées/XAML), ce qui devrait faire de /m:1 un correctif valide à nouveau.
Comme Buck Hodges et Nimblejoe l'ont dit à juste titre, cela est principalement dû au fait que TFS exécute plusieurs processus MSBuild par défaut pour générer vos projets.
Vous pouvez le remplacer dans la définition de construction dans Process -> 3. Advanced -> MSBuild Arguments en ajoutant l’argument MSBuild/p: BuildInParallel = false
Cela peut également se produire si un dossier d'agent de génération est ouvert.
J'ai aussi eu le même problème. J'ai eu des messages d'erreur liés à ne peut pas copier depuis l'accès au chemin refusé. Dans mon cas, tous mes fichiers DLL et XML, etc., sont placés dans le dossier D:\TFS\Example\Bin\Debug.
J'ai cliqué avec le bouton droit sur le dossier Bin, cliqué sur Propriétés et constaté que la case à cocher en lecture seule est cochée sous Attributs.
J'ai décoché la case à cocher Lecture seule et cliqué sur Appliquer, puis sur OK dans la nouvelle fenêtre contextuelle affichée.
Je suis retourné à Visual Studio et ai construit ma solution qui me donnait des messages d'erreur.
Voilà .. Cette fois, il construit avec succès sans erreurs.
Je ne sais pas si c'est parfait, mais je l'ai fait pour résoudre mon problème.
Pour contourner ce problème, j'ai dû supprimer l'indicateur "ReadOnly" sur le répertoire source.
Puis, dans le jeu de définitions de construction, nettoyer l'espace de travail
à Aucun
Comme Ziggler, j'ai résolu ce problème en construisant un projet en supprimant la propriété 'lecture seule' du dossier bin de mon projet. Cela se produit uniquement dans les fichiers XML stockés dans un répertoire/packages/commun à la solution contenant ce projet. Le dossier 'bin' n'est pas archivé dans le contrôle de source. Je suis toujours perplexe quant à la cause première du problème.
Voici une variante de ce problème que j'ai eu à traiter:
Je n'arrivais pas à comprendre pourquoi ma génération échouait constamment sur l'erreur "L'accès au chemin est refusé", même si j'avais ajouté des éléments tels que /p:BuildInParallel=false et /p:OverwriteReadOnlyFiles=true aux arguments MSBuild de ma version XAML. La cause s'est avérée être un " Ligne de commande d'événement post-génération " dans les propriétés de mon projet.
Après avoir changé
%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
l'erreur est partie.
J'ai trouvé le même problème qui s'est produit après que la compilation ait essayé de remplacer les fichiers du "Répertoire de travail" qu'il avait créé lors d'une précédente tentative de génération. (défini dans l'agent)
J'ai résolu ce problème en supprimant manuellement le dossier de sortie créé (dans mon cas, [Répertoire de travail]\Fichiers binaires) avant de tenter la construction.
Cela peut être fait automatiquement en modifiant la définition de construction. Sous Processus --- 2.Basic --- Nettoyer l'espace de travail définissez cette option sur l'optionSorties
Une des causes possibles est si vous avez les dossiers bin ou obj pour les bibliothèques de classes archivées dans TFS. La suppression des dossiers bin ou obj des projets de TFS résoudra ce problème si tel est le cas.
J'avais ce problème avec TFS 2015 . Il s'est avéré que l'agent de génération s'exécutait sous les informations d'identification par défaut (NETWORK SERVICE), qui ne disposaient pas d'autorisations d'écriture sur le dossier cible . d a supprimé l'agent et l'a réinstallé avec les informations d'identification qui ont fonctionné . Il m'a fallu parcourir les journaux pendant un certain temps, cocher et décocher la case multi-proc et même redémarrer le serveur de génération dans ma chasse . des choses évidentes d'abord ...
Pour moi, c'est que l'agent de génération n'a pas été démarré dans un administrateur PowerShell.
J'avais ce problème et j'ai choisi de l'ignorer parce que je ne voulais pas sacrifier les performances de construction pour me débarrasser de certains messages d'erreur bénins de NuGet. Cependant, il semble que je suis tombé sur une solution en essayant de résoudre un autre problème, et je pense que cela est lié. Je pense que l'ordre d'extraction des paquets NuGet est lié à l'ordre de construction des projets dans la solution. Donc, si cela est devenu disjoint d'une manière ou d'une autre, NuGet peut être la première victime avant que vous ne rencontriez des erreurs de génération où vous commencez à obtenir le message "Le fichier de métadonnées 'XXX.dll' n'a pas pu être trouvé", erreurs qui vous obligent à créer à nouveau jusqu'à la réussite de la construction (comme décrit ici ).
Je pense donc que la solution consiste à suivre les étapes décrites dans la réponse acceptée à la question susmentionnée. Ou suivez les étapes plus complètes de une des réponses alternatives . En d’autres termes, désactivez la construction de tous les projets, redémarrez VS, puis réactivez la construction de tous les projets. Cela résoudra (normalement) l'ordre de génération. Et cela devrait, espérons-le, résoudre le problème NuGet. S'il vous plaît laissez-moi savoir si cela corrige pour quiconque.