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

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

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

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

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

обновление: по-видимому, TFS 2015 больше не переопределяет ваш /m:1 С /m (даже в определениях сборки legacy/XAML), которые должны сделай /m:1 снова допустимое исправление.

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

вы можете переопределить его в определении сборки в

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

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

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

Я снял флажок только для чтения и щелкнул применить и нажал OK на новом всплывающем окне, которое показано.

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

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

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

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

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

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

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

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

Я не мог понять, почему моя сборка продолжала терпеть неудачу при ошибке "доступ к пути запрещен", хотя я добавил такие вещи, как /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

ошибки пошли прочь.

чтобы обойти эту проблему, мне пришлось удалить флаг "ReadOnly" в исходном каталоге

затем в определение построения, установите чистую рабочую поверхность.

до нет

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

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

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

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

для меня это было то, что агент сборки не был запущен в Администраторе powershell.

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

реальная проблема заключается в том, что 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/

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