Копія команди, що виходить із кодом 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

Коли ви отримуєте копію команди, що вийшов із помилкою коду [ввести значення], це зазвичай відбувається через наступне:

• дозволи на читання / запис
• відсутні файли
• неправильні каталоги

Однак - очевидно, в моменти, коли я будую рішення, проблем немає.

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

У вас була та сама проблема і її вирішили? Або у вас є якесь можливе рішення?

Я незмінно вважав це проблемою блокування файлів. Код 4 - не вдається отримати доступ до файлу. Одне часткове рішення, яке я знайшов, - використовувати параметр / C для xcopy (який продовжується помилково). Насправді не рішення, але, в основному, це зупинило невдачу моїх конструкцій.

Ще одне рішення, яке працює лише на 32-бітному, - використовувати інструмент розблокування , щоб звільнити вікна ручок у файлі перед копією.

Редагувати: Я щойно зрозумів, що він працює і під 64 бітами.

Хоча /Cпомилки можуть ігноруватись, це може бути не справжнім рішенням, оскільки можуть бути файли, ОБОВ'ЯЗКОВІ скопійовані, щоб збірка була успішною.

Найпоширеніша проблема - відсутні цитати навколо заздалегідь визначених командних тегів (наприклад, $TargetDir). Коли ви створюєте різні гілки та контури в коді або TFS, є дуже високий шанс цього статися.

Іноді, якщо файл читається лише він, це також спричинить проблеми. Додайте /Rопцію, щоб дозволити копіювання файлів лише для читання. Список доступних варіантів ви можете знайти за адресою:

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

Інша можлива проблема полягає в тому, що базову папку не можна отримати. Якщо так, спробуйте виконати "start xcopy"замість "xcopy". Це відкриє ще одне вікно команд, але з правами адміністратора.

Я перекреслив ту саму помилку, але це не через те, що файл заблокований, але файл відсутній.

Причина, через яку VS намагався скопіювати неіснуючий файл, полягає в команді події після складання.

Після того, як я це усунув, проблема вирішена.

ОНОВЛЕННЯ:

Як прокоментував @rhughes:

Справжня проблема полягає в тому, як змусити команду працювати тут, а не видаляти її.

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

Я також стикався з цією проблемою. Подвійно перевіряйте результат у вікні помилок.

У моєму випадку \хвіст вибивав з ладу xcopy (як я використовував $(TargetDir)). У моєму випадку $(SolutionDir)..\bin. Якщо ви використовуєте будь-який інший вихід, це потрібно відкоригувати.

Також зауважте, що start xcopyце не виправляється, якщо помилка зникла після компіляції. Можливо, щойно було придушено командним рядком, і жоден файл фактично не був скопійований!

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

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

Як згадується на багатьох сайтах, для цього є різні причини. Для мене це було пов’язано з довжиною джерела та пункту призначення (довжина шляху). Я спробував xcopy в командному рядку, і мені не вдалося набрати повне джерело та шлях (після деяких символів це не дозволить вам вводити). Потім я зменшив довжину шляху і зміг бігти. Сподіваюся, це допомагає.

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

Я отримав цю помилку, оскільки обліковий запис користувача, під яким працює служба TFS Build Service, не мав дозволу писати в цільову папку. Right-click on the folder-->Properties-->Security.

Це може статися в декількох випадках:

1. Коли шлях повного рядка більше 254 символів.
2. Коли ім'я файлу, який потрібно скопіювати, неправильне.
3. Коли цільовий шлях невірний.
4. Коли атрибут readonly встановлений у скопійованому файлі або цільовій папці.

Я отримав цю помилку через те, що файл був відкритий в іншому екземплярі.

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

Я зіткнувся з тим же питанням у випадку XCOPY після того, як буде зроблено збірку. У моєму випадку ця проблема сталася через дозволу ЧИТАТИ НАДАЛЬНО у папках.

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

Сподіваюся, це комусь допоможе!

У мене була така ж помилка з xcopy у зв'язку з Test Engine. Я використовую VisualStudio Professional 2013. За замовчуванням Тест -> Налаштування тестування -> Зберігати запуск тестового виконання двигуна, здається, є причиною мого коду помилки 4 з xcopy. Вимкнення його вирішило проблему. Двигун виконання, здається, тримається на деяких .dlls.

У мене була така ж проблема. Простий "Чистий розчин" у VS очистив помилку, але це було тимчасовим рішенням.

Я виявив, що встановлення параметра файлу «Копіювати у вихідний каталог» на «Копіювати завжди», здається, усунуло проблему блокування. Хоча зараз у мене є 2 копії файлів і потрібно видалити один.

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

exit 0

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

Сподіваюся, це допоможе комусь!

Якщо ви працюєте з Windows 7 далі, ви можете спробувати нову команду "robocopy":

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

Більше інформації про робокопію можна знайти тут .

Я зіткнувся з тим же питанням. Я видалив події після складання, і він почав працювати. Деколи, коли ми додаємо деякі компоненти SQL, вони також можуть додавати команди для побудови.

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

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

Шукайте будь-який процес, з якого може бути використаний файл, і закрийте його.

Що це зафіксувало для мене : перейдіть до конкретного рішення для потрібного проекту, тобто НЕ загальний файл рішення для всіх проектів.

Спробуйте - я спробував усе інше, що згадується тут, але безрезультатно.

Я нічого не бачу тут, щоб припустити, що це веб-додаток, але я сам випробував цю проблему - у мене є дві команди xcopy для події після збирання, і лише одна з них вийшла з ладу. Щось було заблоковано у файлі, і це не Visual Studio (як я намагався його перезапустити.)

Єдине, що використовував би побудований dll - IIS. І ось, ось

Простий iisresetзробив трюк для мене.

У мене було те саме питання. Це було спричинено тим, що один і той же прапор був двічі, наприклад:

якщо $ (ConfigurationName) == Release (xcopy "$ (TargetDir) . " "$ (SolutionDir) Розгортання \ $ (ProjectName) \" / e / d / i / y / e)

Зауважте, що прапор "/ e" з'являється двічі. Видалення дубліката вирішило проблему.

У моєму випадку мій $(OutDir)простий ..\..\Build\шлях, тобто І, коли я намагався скопіювати наступне xcopy /y "$(OutDir)Proj1.dll" "Anypath\anyfolder\" я отримував помилку вихідного коду 4.

Що сталося, ця команда виконувалась у самій $ (OutDir) (у моєму випадку папка build), а не в каталозі, де знаходився файл csproj проекту (як ми зазвичай очікували). Отже, я продовжував отримуватиFile not found помилку (відповідає коду виходу 4).

Я не міг цього зрозуміти, поки не написав cdу подіях Post Build, щоб надрукувати, в якому каталозі це виконується.

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

Може бути викликано робочою станцією VMWare зі спільними папками

У мене проблема завжди, коли папка destinatinon xcopy також відображається як Спільна папка у ВМ.

Я вирішив це за допомогою сценарію, запущеного в vm та видалення вмісту спільної папки.

Щоб розширити відповідь на регш,

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

Також robocopy повідомить про декілька речей, наприклад, якщо нові файли були скопійовані, це призведе до того, що VS скаржиться, оскільки все, що перевищує 0, - це збій, і robocopy поверне 1, якщо нові файли знайдені. Варто зазначити, що робокопія спочатку порівнює джерело / ціль і лише копіює оновлені / нові файли.

Щоб обійти це використання:

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

Якщо ви знаходитесь тут, тому що ваш проект не може побудувати на сервері збірки, але добре "вручну" створює машину розробників, і ви робите xcopyлише для налагодження та емуляції виробничого середовища на машині розробників, то, можливо, ви захочете подивитися при такому рішенні:

https://stackoverflow.com/a/1732478/2279059

Ви просто вимикаєте події збирання повідомлення на сервері збірки за допомогою

msbuild foo.sln /p:PostBuildEvent=

Це недостатньо добре, якщо у вас є інші події після складання, які також потрібно запустити на сервері збірки, і це не є загальним рішенням. Однак, оскільки існує стільки різних причин цієї проблеми, загального рішення не може бути. Один із численних відповідей на це питання (та його дублікати), ймовірно, допоможе, але будьте обережні з підходами, які лише якось обходять обробку помилок (наприклад, xcopy /C). Вони можуть працювати для вас, особливо також у сценарії побудови сервера, але я думаю, що цей варіант є більш надійним, якщо його можна використовувати.

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

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

Це може бути проблема блокування файлів, пов’язана з паралельною побудовою. Не можна використовувати паралельну побудову. Це поведінка за замовчуванням, але якщо ви використовуєте -mпараметр, проекти будуватимуться паралельно. Наступні варіанти не повинні створювати проекти паралельно, тому ви не зіткнетесь із проблемою блокування файлів.

msbuild -m:1
msbuild -maxcpucount:1
msbuild

Зауважте, що, всупереч сказаному тут, це відбувається навіть із "останньою" версією MSBuild (з Інструменти побудови для Visual Studio 2019).

Найкраще рішення - це, мабуть, переконатися, що вам не потрібно копіювати файли на етапі після збирання. У деяких ситуаціях ви також можете відключити кроки після збирання при побудові з MSBuild на сервері збірки: https://stackoverflow.com/a/55899347/2279059