Командная копия завершена с кодом 4 при создании - рестарт Visual Studio решает его

Время от времени, когда я строю свое решение здесь (с 7 проектами в нем), я получаю страшную ошибку "Копия команды завершена с кодом 4", в Visual Studio 2010 Premium ed.

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

Вот что решает проблему, временно

  • Иногда: перезапуск Visual Studio, и я могу построить решение
  • Иногда: и перезапуск Visual Studio, и мой файловый менеджер (Q-Dir 4.37) решают эту проблему.

Вот как выглядит событие после сборки:

xcopy "$(SolutionDir)Solution Items\References\*.dll" "$(TargetDir)" /Y

Когда вы получаете завершение команды copy с ошибкой code [insert value], обычно это происходит из-за следующего:

  • разрешения на чтение/запись
  • недостающие файлы
  • неправильные каталоги

Однако, очевидно, иногда, когда я строю решение, проблем не возникает.

К вашему сведению, я удалил ReSharper 5.1.1 две недели назад, и Visual Studio с тех пор давала мне некоторые ошибки (среди которых не было возможности отладки). Я переустанавливал Visual Studio, и с тех пор он работал лучше, но проблема все равно осталась. Может ли это быть связано с тем, что где-то есть ReSharper?

У вас была такая же проблема и вы решили ее? Или у вас есть какое-нибудь возможное решение?

Ответ 1

Я всегда считал, что это проблема блокировки файлов. Код 4 не может получить доступ к файлу. Одно частичное решение, которое я нашел, это использовать параметр /C для xcopy (который продолжается при ошибке). На самом деле это не решение, но в основном это остановило мои сборки от сбоев.

Другим решением, которое работает только с 32-битным, является использование unlocker, чтобы выпустить дескрипторы окон в файл перед копией.

Изменить: я только что понял, что он работает и под 64 бит.

Ответ 2

В то время как /C может игнорировать ошибки, это может быть не реальное решение, так как могут быть файлы, которые ДОЛЖНЫ копироваться, чтобы сборка была успешной.

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

Иногда, если файл только для чтения, это также вызовет проблемы. Добавьте параметр /R, чтобы разрешить копирование только файлов, предназначенных для чтения. Список доступных опций можно найти по адресу:

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/xcopy.mspx?mfr=true

Другая возможная проблема заключается в невозможности доступа к основной папке. Если это так, попробуйте выполнить "start xcopy" вместо "xcopy". Это откроет другое командное окно, но с правами администратора.

Ответ 3

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

Причина, по которой VS попытался скопировать несуществующий файл, заключается в команде события Post-build.

После того, как я это очистил, проблема решена.

ОБНОВИТЬ:

Как заметил @rhughes:

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

и он абсолютно прав.

enter image description here

Ответ 4

Я также столкнулся с этой проблемой. Дважды проверьте результат в окне ошибки.

В моем случае хвост \ терпел крах xcopy (как я использовал $(TargetDir)). В моем случае $(SolutionDir)..\bin. Если вы используете какой-либо другой выход, это необходимо отрегулировать.

Также обратите внимание, что start xcopy не исправляет это, если ошибка исчезла после компиляции. Это может быть просто отключено командной строкой, и файл не был скопирован!

Вы можете вручную выполнить команды xcopy в командной оболочке. Вы получите более подробную информацию при их исполнении, указав, что вы в правильном направлении.

Ответ 5

Если событие post build содержит команду copy/xcopy для копирования вывода сборки в какой-либо каталог (который обычно является наиболее распространенной операцией пост-сборки), проблема может возникнуть в случае, если полный путь к каталогу из исходных или целевых адресатов содержит папку имена, которые включают пробелы. Удалите место для имен каталогов и попробуйте.

Ответ 6

Как упоминалось на многих сайтах, для этого есть разные причины. Для меня это было связано с длиной источника и места назначения (длина пути). Я попробовал xcopy в командной строке, и мне не удалось ввести полный источник и путь (после некоторых символов он не позволит вам вводить). Затем я уменьшил длину пути и смог запустить. Надеюсь, это поможет.

Ответ 7

Я получил эту ошибку, потому что учетная запись пользователя, с которой была запущена служба сборки TFS, не имела прав на запись в папку назначения. Right-click on the folder-->Properties-->Security.

Ответ 8

Это может произойти в нескольких случаях:

  • Когда полный путь строки длиннее 254 символов.
  • Если имя файла, который нужно скопировать, неверно.
  • Если целевой путь неправильный.
  • Когда атрибут readonly установлен в скопированном файле или целевой папке.

Ответ 9

Запустите VS в режиме администратора, и он должен работать нормально.

Ответ 10

Я получил эту ошибку из-за того, что файл был открыт в другом экземпляре.

когда я закрыл файл и снова заново построил решение, он был успешно скопирован.

Ответ 11

Я столкнулся с той же проблемой в случае XCOPY после завершения сборки. В моем случае проблема происходила из-за разрешений READ-ONLY, установленных в папках.

Я добавил команду attrib -R перед XCOPY и решил проблему.

Надеюсь, это поможет кому-то!

Ответ 12

У меня была такая же ошибка с xcopy в связи с Test Engine. Я использую VisualStudio Professional 2013. По умолчанию Test → Test Settings → Keep Test Execution Engine Running, по-видимому, является причиной моего кода ошибки 4 с помощью xcopy. Выключение этой проблемы решило проблему. Механизм выполнения, похоже, держится за некоторые DLL.

Ответ 13

У меня была та же проблема. Простое "чистое решение" в VS очистило ошибку, но это временное решение.

Ответ 14

Я обнаружил, что установка параметра "Копировать в выходной каталог" в "Копировать всегда", похоже, устраняет проблему блокировки. Хотя теперь у меня есть 2 копии файлов и их нужно удалить.

Ответ 15

У меня была та же проблема. Однако для меня ничего не работало. Я решил проблему, добавив

exit 0

в мой код. Проблема заключалась в том, что, когда я делал копирование файлов, иногда последний файл не мог быть найден, и летучая мышь вернула ненулевое значение.

Надеюсь, это поможет кому-то!

Ответ 16

Если вы используете Windows 7, вы можете попробовать новую команду robocopy:

robocopy "$(SolutionDir)Solution Items\References\*.dll" "$(TargetDir)"

Более подробную информацию о robocopy можно найти здесь.

Ответ 17

Я столкнулся с такой же проблемой. Я удалил события после сборки и начал работать. Иногда, когда мы добавляем некоторые компоненты SQL, он может также добавлять команды post build.

Ответ 18

Я получаю что-то подобное с помощью xcopy с опцией /exclude. В моем случае я обнаружил, что редактирование события после сборки (что-то безвредное, как новая строка после команды) и сохранение проекта приводит к ошибке. Повторное сохранение файла, указанного в опции /exclude, заставляет его работать снова.

Ответ 19

Когда я пишу библиотеку DLL, я использовал команду xcopy для копирования библиотеки, в которой программа может ее найти и загрузить. После нескольких раз открытия и закрытия программы все еще был открытый процесс в taskmanager, который я не узнал.

Посмотрите на любой процесс, из которого файл может быть использован, и закройте его.

Ответ 20

Что исправлено для меня: выкопайте до конкретного решения для проекта, который вы хотите, а не общий файл решения для всех проектов.

Попробуйте - я попробовал все остальное, упомянутое здесь, но безрезультатно.

Ответ 21

Я ничего здесь не вижу, чтобы предположить, что это веб-приложение, но я сам испытал эту проблему. У меня есть две команды xcopy для события после сборки, и только один из них терпел неудачу. Что-то заблокировало файл, и это была не Visual Studio (поскольку я пытался перезапустить его.)

Единственная вещь, которая использовала бы DLL, которую я построил, - это IIS. И вот,

Простой iisreset помогло.

Ответ 22

У меня была такая же проблема. Это было вызвано тем, что один флаг был дважды, например:

если $(ConfigurationName) == Release (xcopy "$ (TargetDir)." "$ (SolutionDir) Развертывание \$(ProjectName) \" /e/d/i/y/e )

Обратите внимание, что флаг "/e" появляется дважды. Удаление дубликата решило проблему.

Ответ 23

В моем случае мой $(OutDir) был просто ..\..\Build\ т.е. некоторый относительный путь. И когда я пытался выполнить xcopy следующим образом xcopy/y "$(OutDir)Proj1.dll" "Anypath\anyfolder\" я получал ошибку кода выхода 4.

Произошло то, что эта команда выполнялась в самом $ (OutDir) (в моем случае папка сборки), а не в каталоге, где находился файл csproj проекта (как мы обычно ожидаем). Следовательно, я продолжал получать File not found (соответствует коду выхода 4).

Я не мог понять это, пока не написал cd в событиях Post Build, чтобы напечатать, в каком каталоге он выполнялся.

Итак, $(OutDir) итог: если мы хотим copy файлы /xcopy из $(OutDir), либо используйте "$(TargetDir)" (который является полным путем для выходного каталога), либо вообще не нужно указывать какой-либо путь.

Ответ 24

Может быть вызвано рабочей станцией VMWare с общими папками

У меня проблема всегда, когда папка destinatinon в xcopy также отображается как общая папка в виртуальной машине.

Я решил его с помощью script, запущенного в vm и удаляющего содержимое общей папки.

Ответ 25

Чтобы расширить на грубый ответ,

Робокопия работает прекрасно, только в том случае, если вам нужно включить подкаталоги, которые вы можете использовать /e чтобы включить подкаталоги, и скопировать пустые каталоги или /s чтобы включить подкаталоги, за исключением пустых каталогов.

Кроме того, robocopy сообщит о некоторых вещах, например, если были скопированы новые файлы, это заставит VS пожаловаться, так как все, что выше 0, является ошибкой, и robocopy вернет 1, если были найдены новые файлы. Стоит отметить, что robocopy сначала сравнивает Source/Dest и только копирует обновленные/новые файлы.

Чтобы обойти это использование:

(robocopy "$(SolutionDir)Solution Items\References\*.dll" "$(TargetDir)") ^& IF %ERRORLEVEL% LEQ 4 exit /B 0

Ответ 26

Если вы находитесь здесь, потому что ваш проект не может быть собран на сервере сборки, но он прекрасно собирается "вручную" на компьютере разработчика, и вы выполняете xcopy только для отладки и эмуляции продакшен среды на компьютере разработчика, тогда вы можете захотеть посмотрите на это решение:

fooobar.com/questions/141512/...

Вы просто отключаете события после сборки на сервере сборки, используя

msbuild foo.sln /p:PostBuildEvent=

Этого недостаточно, если у вас есть другие события после сборки, которые также должны запускаться на сервере сборки, и это не общее решение. Однако, поскольку существует много разных причин этой проблемы, не может быть общего решения. Один из многочисленных ответов на этот вопрос (и его дубликаты), вероятно, поможет, но будьте осторожны с подходами, которые только каким-то образом обходят обработку ошибок (например, xcopy/C). Они могут работать для вас, особенно в сценарии сборки сервера, но я думаю, что этот вариант более надежен, ЕСЛИ его можно использовать.

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

Ответ 27

Код ошибки 4 может означать много вещей, поэтому я рекомендую прочитать и другие ответы, пока не найдете решение, которое работает для вас, и не поймете, ПОЧЕМУ оно работает (некоторые решения отключают только обработку ошибок, которая может только маскировать проблему, но не реши это).

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

msbuild -m:1
msbuild -maxcpucount:1
msbuild

Обратите внимание, что вопреки сказанному здесь, это даже происходит с "последней" версией MSBuild (из Build Tools for Visual Studio 2019).

Лучшее решение, вероятно, - убедиться, что вам не нужно копировать файлы на этапе после сборки. В некоторых ситуациях вы также можете отключить шаги после сборки при сборке с MSBuild на сервере сборки: fooobar.com/info/43997/...