Construire TFS 2012 " accès au chemin refusé"

comme d'autres l'ont mentionné, cela se produit lorsque l'exécution de constructions multithread avec un répertoire de destination commun et que la tâche de copie de fichier rencontre un conflit simultané avec une tâche de copie tournant pour un projet différent.

Normalement, cela devrait aboutir à une exception" fichier utilisé par un autre processus "(qui est traité et récupéré par la tâche de copie de fichier) mais parfois l'opération de fichier résulte en une exception" Accès refusé " à la place. (Je ne suis pas encore assurez-vous pourquoi)

certains suggèrent que vous devriez" résoudre la duplication", mais je ne pense pas que ce soit faisable pour les cas où tous les projets doivent faire référence directement à une bibliothèque comme log4net.

de toute évidence, l'une des façons d'éviter le problème est d'exécuter explicitement msbuild avec /p:BuildInParallel=false ou /m:1 ou /maxcpucount:1 (ou d'omettre entièrement l'argument) pour forcer le mode mono-threadé.

cependant, dans TFS 2013 , le modèle de construction par défaut passe automatiquement /m (utilisez tous les noyaux) à msbuild, ce qui remplace silencieusement tout paramètre de thread simple que vous pouvez passer manuellement. (Déterminée par mes propres expériences et l'examen des journaux de diagnostic)

une autre solution que j'ai essayé était de passer manuellement /p:AllowedReferenceRelatedFileExtensions=none à msbuild, ce qui empêche tous les fichiers pdb et xml d'être copiés à partir de bibliothèques référencées. (Depuis un certain temps, je n'ai vu que les fichiers xml ayant 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écomposant 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 (accès 0x80070005 est refusée) se produit, la tâche de copie vérifiera une variable spéciale pour voir si elle devrait réessayer. Cette valeur est définie par une variable d'environnement:

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

après avoir fixé l'environnement variable MSBUILDALWAYSRETRY = 1 (et redémarrage du serveur de compilation), le problème a disparu. Et j'ai aussi périodiquement commencé à voir des "Réessayer sur ERROR_ACCESS_DENIED..."comme des avertissements dans les journaux de construction, prouvant que le réglage prenait effet, (au lieu des constructions simplement par coïncidence succéder).

(noter que cette variable d'environnement n'est pas bien documentée, utiliser comme il convient.)

mise à Jour: apparemment TFS 2015 ne remplace plus votre /m:1 par /m (même sur les définitions de construction legacy/XAML), ce qui devrait faire de /m:1 un correctif valide à nouveau.

comme Buck Hodges et Nimblejoe l'ont dit à juste titre, ceci est principalement dû au fait que TFS exécute plusieurs processus MSBuild par défaut pour construire vos projets.

vous pouvez l'Annuler dans la définition de construction dans processus -> 3. Advanced - > MSBuild Arguments en ajoutant L'argument MSBuild /p: BuildInParallel=false

cela peut aussi se produire si vous avez un dossier d'agent de compilation ouvert.

j'ai aussi eu le même problème. J'ai eu des messages d'erreur qui se rapportaient à impossible de copier depuis l'accès au chemin refusé. Dans mon cas, tous mes fichiers dll et xml et ainsi de suite sont placés à D:\TFS\Example\Bin\Debug dossier.

j'ai cliqué droit sur le dossier Bin et cliqué propriétés et j'ai vu que la boîte à cocher en lecture seule est cochée sous attributs.

j'ai décoché la case à cocher Read only et cliked Apply et cliqué OK sur le nouveau popup qui s'affiche.

je suis retourné à Visual Studio et j'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 j'ai fait ça pour résoudre mon problème.

comme Ziggler, j'ai résolu ce problème en construisant un projet en enlevant la propriété "lecture seule" du dossier bin dans mon projet. Cela n'arrive qu'aux fichiers XML stockés dans un répertoire /packages/ qui est commun à la solution qui contient ce projet. Le dossier 'bin' n'est pas vérifié dans le contrôle source. Je suis encore perplexe quant à la cause profonde du problème.

j'ai trouvé le même problème qui s'est produit après que le build ait essayé d'écraser des fichiers dans le" répertoire de travail " qu'il avait créé dans une tentative précédente de construire. (défini dans L'Agent)

j'ai résolu ce problème en supprimant manuellement le dossier de sortie qu'il a créé (dans mon cas [répertoire de travail]\binaires) avant d'essayer la compilation.

cela peut être fait automatiquement en changeant la définition de construction. En Vertu De L' Processus --- 2.De base --- Nettoyer l'espace de travail définir ce à le Sorties option

voici une variante de ce problème que j'ai eu à traiter:

Je ne pouvais pas comprendre pourquoi ma construction continuait à échouer sur une erreur" L'accès au chemin est refusé", même si j'avais ajouté des choses comme /p:BuildInParallel=false et /p:OverwriteReadOnlyFiles=true aux Arguments MSBuild de ma construction XAML. La cause s'est avérée être un " Post-build event ligne de commande " dans les propriétés de mon projet.

après changement

%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 a disparu.

pour contourner ce problème, j'ai dû enlever le drapeau" ReadOnly " sur le répertoire source

puis dans la définition de construction définir espace de travail propre

à néant

une cause possible est si vous avez les dossiers bin ou obj pour les bibliothèques de classe enregistré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 et j'ai choisi de l'ignorer parce que je ne voulais pas sacrifier la performance de construction pour me débarrasser de quelques messages d'erreur bénins par NuGet. Cependant, il semble que j'ai trouvé une solution en essayant de résoudre un autre problème, et je pense que c'est lié. Je pense que l'ordre de récupération des paquets NuGet est lié à l'ordre de construction des projets dans la solution. Donc, si cela a quelque peu été décousu, alors NuGet peut être la première victime avant vous exécutez dans construire des erreurs où vous commencez à obtenir " fichier de métadonnées "XXX.dll' n'a pas pu être trouvé " les erreurs qui exigent de manière gênante de construire à nouveau jusqu'à ce que la construction réussit (comme décrit ici ).

donc, je crois que la solution est de suivre les étapes décrites dans la réponse acceptée à la question susmentionnée. Ou, suivez les étapes dans l'une des réponses alternatives . En d'autres termes, désactiver la construction de tous les projets, redémarrer VS, puis réactiver la construction de tous les projets. Ceci résoudra (normalement) l'ordre de construction. Et ça devrait résoudre la question des Nugets. S'il vous plaît, faites-moi savoir si cela le Répare pour quelqu'un.

j'ai eu ce problème, avec TFS 2015. Il s'est avéré que c'était parce que l'Agent de compilation tournait sous les identifiants par défaut (SERVICE réseau), qui n'avaient pas de permissions d'écriture sur le dossier cible. Une fois que j'ai retiré L'Agent et que je l'ai réinstallé avec des justificatifs d'identité, ça a marché. Il m'a fait parcourir les logs pendant un certain temps, en vérifiant et décochant la boîte multi-proc et même en redémarrant le serveur de compilation dans ma chasse. Vérifiez les choses évidentes d'abord...

pour moi, c'est que l'agent de construction n'a pas démarré dans une powershell d'administrateur.

comme beaucoup de gens l'ont déjà dit, cela se produit lors de la construction de projets en parallèle. Les projets A et B faisant référence à la bibliothèque de tierce partie C (copie locale) provoqueront cette situation lorsqu'ils seront construits en même temps, côte à côte.

le vrai problème est, que TFS Build 2012 et ci-dessous sont configurés que lors de la construction d'une solution, la totalité de la sortie de la solution est copiée dans un dossier unique. C'est là que les douleurs des constructions parallèles ont leur origine.

depuis TFS 2013, vous pouvez facilement résoudre ce problème en définissant l ' "emplacement de sortie" dans la définition de construction en "PerProject". Cela force les services de construction à se comporter comme une exécution locale msbuild où les paramètres concernant les emplacements de sortie sont lus à partir des fichiers de projet correspondants. Ainsi, la sortie est écrite dans les dossiers bin sous chaque projet.

pour TFS 2012 et ci-dessous cet article (+articles liés) vous aidera à obtenir le même résultat qu'avec TFS 2013:

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

j'ai résolu un problème très similaire en fermant toutes les instances ouvertes de Visual Studio, en rouvrant la solution et en la construisant à nouveau.