TFS 2012 Build "Доступ к пути запрещен"

Ответ 1

Похоже, что есть два проекта, копирующих один и тот же файл. В зависимости от времени они иногда происходят одновременно, что приводит к сбою. Вам нужно отследить идентификатор node, чтобы найти исходный проект. Подробнее см. http://blogs.msdn.com/b/buckh/archive/2012/01/21/a-tool-to-find-duplicate-copies-in-a-build.aspx для получения более подробной информации и кода, который может отслеживать его.

Ответ 2

Как уже упоминалось, это происходит при выполнении многопоточных сборников с общим целевым каталогом, и задача копирования файлов сталкивается с одновременным конфликтом с задачей копирования, выполняемой для другого проекта.

Обычно это должно привести к исключению "файла, используемого другим процессом" (которое обрабатывается и повторно выполняется задачей копирования файлов), но иногда операция с файлом приводит к исключению "Отказано в доступе". (Я все еще не уверен, почему)

Некоторые полагают, что вам следует "разрешить дублирование", но я не вижу такой возможности для случаев, когда все проекты должны напрямую ссылаться на библиотеку, такую ​​как log4net.

Очевидно, одним из способов предотвратить проблему является явное выполнение msbuild с помощью /p:BuildInParallel=false или /m:1 или /maxcpucount:1 (или опускание аргумента целиком) для принудительного однопоточного режима.

Однако в 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 (и перезапуска сервера сборки) проблема исчезла. И я также периодически начинал видеть "Retrying on ERROR_ACCESS_DENIED..." в качестве предупреждений в журналах построения, доказывая, что этот параметр вступил в силу (вместо сборок просто совпадение с успехом).

(Обратите внимание, что эта переменная среды недостаточно хорошо документирована, используйте по мере необходимости.)

Обновление: По-видимому, TFS 2015 больше не переопределяет ваш /m:1 с помощью /m (даже в определениях устаревших/XAML-конструкций), что должно снова сделать исправление /m:1.

Ответ 3

Как справедливо сказали Бак Ходжес и Нимблжо, это связано с тем, что по умолчанию TFS запускает несколько процессов MSBuild для создания ваших проектов.

Вы можете переопределить его в определении сборки в Process → 3. Advanced → MSBuild Arguments, добавив аргумент MSBuild /p: BuildInParallel = false

Ответ 4

Это также может произойти, если открыта папка агента сборки.

Ответ 5

У меня также была такая же проблема. Я получил сообщения об ошибках, связанные с невозможностью копирования, поскольку доступ к пути запрещен. В моем случае все мои файлы dll и xml и т.д. D:\TFS\Example\Bin\Debug.

Я щелкнул правой кнопкой мыши по папке Bin и нажал "Свойства" и увидел, что флажок "Только для чтения" отмечен в разделе "Атрибуты".

Я снял флажок "Только для чтения" и кликнул "Применить" и нажал "ОК" на появившемся всплывающем окне.

Я вернулся в Visual Studio и создал свое решение, которое давало мне сообщения об ошибках.

Voilaa.. На этот раз он успешно строится без ошибок.

Я не знаю, идеально ли это, но я сделал это, чтобы решить мою проблему.

Ответ 6

Одна из возможных причин: если у вас есть папки bin или obj для проверки библиотек классов в TFS. Удаление каталогов bin или obj проектов из TFS разрешит эту проблему, если это так.

Ответ 7

Как и Ziggler, я решил эту проблему при создании проекта, удалив свойство "только для чтения" папки bin в моем проекте. Это происходит только с файлами XML, хранящимися в каталоге /packages/, который является общим для решения, содержащего этот проект. Папка "bin" не проверяется в исходном элементе управления. Я все еще в тупике относительно основной причины проблемы.

Ответ 8

Я обнаружил ту же проблему, которая возникла после того, как сборка попыталась переписать файлы в "Рабочий каталог", которые она создала в предыдущей попытке сборки. (установлено в Агенте)

Я решил это, вручную удалив созданную папку вывода (в моем случае [Рабочий каталог]\Binaries) перед попыткой сборки.

Это можно сделать автоматически, изменив определение сборки. В Процесс --- 2.Basic --- Чистое рабочее пространство установите этот параметр Выходы

Ответ 9

Вот вариация этой проблемы, с которой мне пришлось иметь дело:

Я не мог понять, почему моя сборка не срабатывала при ошибке "Доступ к пути отрицается", хотя я добавил такие вещи, как /p:BuildInParallel=false и /p:OverwriteReadOnlyFiles=true в аргументы MSBuild моей сборки XAML. В моих свойствах проекта причина оказалась " Командная строка событий после сборки.

После изменения

%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

ошибка исчезла.

Ответ 10

У меня была эта проблема, и я решил проигнорировать ее, потому что я не хотел жертвовать производительностью сборки ради того, чтобы избавиться от некоторых сообщений об ошибках NuGet. Тем не менее, я, кажется, наткнулся на решение, пытаясь решить еще одну проблему, и я думаю, что это связано. Я думаю, что порядок загрузки пакетов NuGet связан с порядком сборки проектов в решении. Так что если это каким-то образом разобьется, то NuGet может стать первой жертвой, прежде чем вы столкнетесь с ошибками сборки, когда вы начинаете получать "файлы метаданных XXX.dll" не могут быть найдены ", которые досадно требуют, чтобы вы снова строили, пока сборка не завершится успешно (как описано здесь).

Итак, я считаю, что решение состоит в том, чтобы следовать шагам, описанным в принятом ответе на вышеупомянутый вопрос. Или выполните более подробные шаги в одном из альтернативных ответов. Другими словами, отключите построение всех проектов, перезапустите VS, а затем снова включите создание всех проектов. Это (как правило) разрешит порядок сборки. И это должно надеяться решить проблему NuGet. Пожалуйста, дайте мне знать, если это исправлено для всех.

Ответ 11

У меня была эта проблема с TFS 2015. Это оказалось потому, что агент сборки работал под учетными данными по умолчанию (NETWORK SERVICE), у которых не было прав на запись в целевой папке. Как только я удалил агент и переустановил его с учетными данными, он сработал. Мне приходилось некоторое время тратиться через журналы, проверяя и снимая флажок с несколькими процессорами и даже перезапуская сервер сборки в своей охоте. Сначала проверьте очевидные вещи...

Ответ 12

как уже было сказано ранее, это происходит при параллельном строительстве проектов. Проекты A и B, ссылающиеся на стороннюю библиотеку C (Копировать локальную), вызовут это, когда они будут построены в одно и то же время - бок о бок.

Реальная проблема заключается в том, что TFS Build 2012 и ниже настроены так, что при построении решения весь вывод решения копируется в одну папку. То, где боли в параллельных построениях имеют свое происхождение.

С TFS 2013 вы можете легко решить эту проблему, установив "местоположение вывода" в определении сборки "PerProject". Это заставляет службы построения вести себя как локальный прогон msbuild, где настройки относительно местоположений вывода считываются из соответствующих файлов проекта. Таким образом, вывод записывается в папки bin под каждым проектом.

Для TFS 2012 и ниже этой статьи (+ связанные статьи) вы получите тот же результат, что и с TFS 2013:

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

Ответ 13

Я решил очень похожую проблему, закрыв все открытые экземпляры Visual Studio, снова открыв решение и построив его снова.