xcopy не розпізнається як внутрішня або зовнішня команда, операційна програма або пакетний файл

У мене проблема з використанням команди 'xcopy'.

Я будую проект C# з msbuild. Наприкінці збірки викликається пакетний файл для копіювання моїх збірок з Debug/Release в інші папки.

Ось проблема, моя помилка збирання і журнал помилок 'xcopy не розпізнається як внутрішня або зовнішня команда, робоча програма або пакетний файл'.

Шлях правильно встановлений, xcopy працює з командного рядка Windows і з командного рядка візуальної студії (той, який встановлено в середовищі проекту).

Я спробував встановити шлях у пакетному файлі, але це не допомагає.

Будь-яка пропозиція?

Я використовую Windows 7

Привітання:

28

7 Відповіді

Я зіткнувся з тією ж проблемою.

Здається, це проблема з змінною середовища шляху у Visual Studio.

Коли я додав заяву "шлях" до початку моєї події збирання, він зробив наступний висновок:

PATH=

Це вказує на те, що шлях у середовищі побудови VS порожній.

Коли я вказую повний шлях до xcopy, ця проблема вийшла:

%systemroot%\System32\xcopy ...

Я не впевнений, що змусило Visual Studio втратити свій шлях.

38
додано

Set Environment variable PATH = %systemRoot%\system32;%systemRoot%;%systemRoot%\System32\Wbem;%sYSTEMROOT%\System32\WindowsPowerShell\v1.0\

11
додано

Це сталося зі мною після того, як я оновив одну з моїх розширень Visual Studio, під час яких Visual Studio закривався і знову відкривався оновленням. Я більше не міг правильно будувати свій проект. Я закрив Visual Studio і знову відкрив його, і проблема пішла.

6
додано
Те ж саме. Закриваючи ВС і відкриваючи його, знову вирішили проблему.
додано Автор Sebastian Krysmanski, джерело

Це не є проблемою у Windows 7 або 8. Це насправді проблема з додатками, які оновлюють змінні середовища, такі як PATH. PATH зберігається в реєстрі як "значення розширюваного рядка" (REG_EXPAND_SZ), але багато додатків записують його до реєстру як "String Value" (REG_SZ). Якщо ваш шлях містить щось подібне до% SYSTEMROOT%, це не буде розгорнуто на C: Windows (або будь-яке інше), якщо шлях міститься в REG_SZ.

Виправлення - це просто редагувати шлях вручну з панелі керування. Потрібно внести зміни (наприклад, додати до кінця шляху), а потім застосувати їх. Це виправити ваш шлях до реєстру, щоб бути REG_EXPAND_SZ. (Перейдіть до Панелі керування системи та оберіть Розширені системні налаштування. Відредагуйте змінну "Навколишнє середовище" у нижньому вікні, і це має виправити.

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

6
додано
Місце на Філа! У моєму випадку це було на Windows XP, і запис у реєстрі (HKEY_LOCAL_MACHINE SYSTEM ControlSet001 Control Manager Середовище шлях) дійсно був встановлений на REG_SZ. Повторне встановлення шляху з панелі керування> Система> Додатково> Зміни середовища виправили його в реєстрі. Коли я запустив новий командний рядок, шлях був належним чином розширений.
додано Автор prairiehat, джерело

Перейдіть до змінної середовища та виправте PATh, включаючи ; у останньому. Це буде працювати, це зовсім не пов'язано з ОС або технологією. Він працює для мене, навіть не потрібно перезапускати ОС, просто відкрийте нову командний рядок.

2
додано

I just experienced this for the first time with a batch file I use to copy an Access front-end app to the user's local machines. Their environment is a mix of Windows 7 & 8 and 32-64 bit machines. I noticed that the xcopy.exe was both in the System32 and the SysWOW64 folders and I wondered if there was some conflict. So -- I copied the xcopy.exe into the folder where the batch file resides and it now seems to be working. Just thought I'd share this.

Ейлін

1
додано

У мене також була проблема з xcopy (таке ж повідомлення про помилку) - з дуже простою пакетною програмою, яку я використовую для резервного копіювання файлів на знімний диск. Використовували цю програму щонайменше 5 років, але ніколи не виникали проблеми. Тоді вчора xcopy невідомий Win7. Заміна xcopy на% systemroot% System32 xopy на кожному прикладі вирішила проблему. Дуже дивно.

0
додано