ошибка MSB6006: & ldquo; cmd.exe & rdquo; с кодом 9009. C: \ Program Files (x86) \ MSBuild \ Microsoft.Cpp \ v4.0 \ V120 \ Microsoft.CppCommon.targets [duplicate]

Еще один вариант файла не найден, из-за пробелов в пути. В моем случае в скрипте msbuild. Мне нужно было использовать стиль HTML & ampquot; строки в команде exec.

<!-- Needs quotes example with my Buildscript.msbuild file --> 
<Exec Command="&quot;$(MSBuildThisFileDirectory)\wix\wixscript.bat&quot; $(VersionNumber) $(VersionNumberShort)" 
    ContinueOnError="false" 
    IgnoreExitCode="false" 
    WorkingDirectory="$(MSBuildProjectDirectory)\wix" />

На самом деле я заметил, что по какой-то причине переменная среды% windir% иногда стирается. То, что сработало для меня, было изменено на переменную среды windir на c: \ windows, перезапустить VS, и все. Таким образом, вы не можете изменять файлы решений.

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

Скорее всего, у вас есть место в результирующем пути.

Вы можете обойти это, указав пути, тем самым позволяя пробелы. Например:

xcopy "$(SolutionDir)\Folder Name\File To Copy.ext" "$(TargetDir)" /R /Y /I

Другой вариант:

сегодня я вызываю интерпретатор python из cron в win32 и беру ExitCode (% ERRORLEVEL%) 9009, потому что системная учетная запись, используемая cron, не имеет пути к каталогу Python.

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

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

Я вызвал эту ошибку, когда я отредактировал переменную окружения Path. После редактирования я случайно добавил Path= в начало строки пути. С такой неправильной переменной пути мне не удалось запустить XCopy в командной строке (никакая команда или файл не найдена), а Visual Studio отказалась выполнить шаг после сборки, указав ошибку с кодом 9009.

XCopy обычно находится в C: \ Windows \ System32. Как только переменная окружения Path разрешила XCopy разрешиться в приглашении DOS, Visual Studio хорошо построила мое решение.

Если скрипт действительно делает то, что ему нужно сделать, и это просто Visual Studio, вызывающий вас об ошибке, которую вы могли бы просто добавить:

exit 0

до конца вашего скрипта.

Это происходит, когда вам не хватает некоторых параметров среды для использования инструментов Microsoft Visual Studio 2010 x86. Поэтому попробуйте добавить в качестве первой команды следующие шаги после сборки:

call "$(DevEnvDir)..\Tools\vsvars32.bat"

Он должен быть помещен перед любой другой командой. Он установит среду для использования инструментов Microsoft Visual Studio 2010 x86.

По крайней мере, в Visual Studio Ultimate 2013, версии 12.0.30723.00 Update 3, невозможно разделить оператор if / else с разрывом строки:

работает:

if '$(BuildingInsideVisualStudio)' == 'true' (echo local) else (echo server)

не работает:

if '$(BuildingInsideVisualStudio)' == 'true' (echo local) 
else (echo server)

Вы пытались дать полный путь к команде, которая запущена в команде pre-or post-build event?

Я получал ошибку 9009 из-за xcopy пост-сборки event в Visual Studio 2008.

Команда "xcopy.exe /Y C:\projectpath\project.config C:\compilepath\" вышла с кодом 9009.

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

Однако в моем случае предоставление команды с полным пути разрешило проблему:

c:\windows\system32\xcopy.exe /Y C:\projectpath\project.config C:\compilepath\ 

Вместо того, чтобы просто :

xcopy.exe /Y C:\projectpath\project.config C:\compilepath\

Если у меня нет полного пути, он запускается некоторое время после перезапуска, а затем останавливается.

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

"C:\The folder with spaces\ABCDEF\xcopy.exe" /Y C:\projectpath\project.config C:\compilepath\

Обратите внимание, что этот пример в отношении пробелов не проверен.

Кроме того, убедитесь, что в окне редактирования событий post build в вашем проекте нет разрывов строк. Иногда копирование команды xcopy из сети, когда она многострочная и вставляет ее в VS, вызовет проблему.

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

Мое решение было просто: как вы пытались отключить его и снова? Поэтому я перезапустил компьютер, и проблема исчезла.

Проверьте орфографию. Я пытался вызвать исполняемый файл, но имел имя с ошибкой и дал мне сообщение exited with code 9009.

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

Чтобы открыть окно вывода в Visual Studio:

1. Ctrl + Alt + O
2. Вид> Выход

В моем случае перед вызовом команды мне пришлось сначала «CD» («Изменить каталог») в соответствующий каталог, так как исполняемый файл, который я вызывал, был в моей директории проекта.

Пример:

cd "$(SolutionDir)"
call "$(SolutionDir)build.bat"

Для меня это произошло после обновления пакетов nuget от одной версии PostSharp до следующего в большом решении (проект ~ 80). У меня есть ошибки компилятора для проектов, которые имеют команды в событиях PreBuild.

'cmd' не распознается как внутренняя или внешняя команда, операционная программа или командный файл. C: \ Program Files (x86) \ MSBuild \ 14.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1249,5): ошибка MSB3073: команда "cmd / c C: \ GitRepos \ main \ ServiceInterfaces \ DEV.Config \ PreBuild.cmd ServiceInterfaces "вышла с кодом 9009.

Изменена переменная PATH, слишком длинная с несколькими повторяющимися путями, связанными с PostSharp.Patterns.Diagnostics. Когда я закрыл Visual Studio и снова открыл его, проблема была исправлена.

Это довольно просто, у меня была эта проблема, и смущающая простая ошибка.

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

Visual Studio -> Свойства проекта -> убедитесь, что вы используете вкладку «Отладка» (не вкладка «Build Events») -> Аргументы командной строки

Я использовал текстовую область Post и Pre-build, которая была неправильной в этом случае.

Еще одна причина: если ваше событие pre-build ссылается на другой путь к bin-файлам, и вы видите эту ошибку при запуске msbuild, но не Visual Studio, тогда вам нужно вручную организовать проекты в файле * .sln (с текстом редактор), чтобы проект, на который вы нацеливаетесь в событии, строится до проекта события. Другими словами, msbuild использует порядок, в котором проекты перечислены в файле * .sln, тогда как VS использует знания зависимостей проекта. Это произошло, когда инструмент, который создает базу данных для включения в wixproj, был указан после wixproj.

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

"$(SolutionDir)\packages\NUnit.Runners.2.6.2\tools\nunit" "$(TargetPath)" 

или если вы используете консоль:

"$(SolutionDir)\packages\NUnit.Runners.2.6.2\tools\nunit-console" "$(TargetPath)"

Это исправило проблему для меня.

Я добавил «> myFile.txt» в конец строки на этапе предварительной сборки, а затем проверил файл на фактическую ошибку.

Ответ tfa был опущен, но на самом деле может вызвать эту проблему. Благодаря hanzolo я посмотрел в окне вывода и нашел следующее:

3>'gulp' is not recognized as an internal or external command,
3>operable program or batch file.
3>D:\dev\<filepath>\Web.csproj(4,5): error MSB3073: The command "gulp clean" exited with code 9009.

После запуска npm install -g gulp я прекратил эту ошибку. Если вы получаете эту ошибку в Visual Studio, проверьте окно вывода и посмотрите, является ли проблема неуправляемой переменной среды.

Имела ту же переменную после изменения переменной PATH из переменных окружения в Win 7. Возвращение к умолчанию помогло.

Моя точная ошибка была

The command "iscc /DConfigurationName=Debug "C:\Projects\Blahblahblah\setup.iss"" exited with code 9009.

9009 означает, что файл не найден, но на самом деле он не смог найти часть «iscc» команды.

Я исправил его, добавив ";C:\Program Files\Inno Setup 5 (x86)\" в переменную системной среды "path"

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

Вам нужно убедиться, что вы установили grunt по всему миру

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

В принципе, если файл уже существует и вы не указали переключатель /y (который автоматически перезаписывается), эта ошибка может произойти при запуске из сборки.