Что означает "выходить с кодом 9009" во время этой сборки?

Ответ 1

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

Я получал ошибку 9009 из-за команды xcopy post-build 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\

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

Ответ 2

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

Ответ 3

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

Для Visual Studio 2010 используйте:

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

Как уже упоминалось в комментариях @FlorianKoch, для VS 2017 используйте:

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

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

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

exit 0

до конца script.

Ответ 9

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

Ответ 10

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

Пример:

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

Ответ 11

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

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

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

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

Ответ 12

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

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

Ответ 13

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

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

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

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

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

Ответ 14

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

Ответ 15

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

Ответ 16

Тфа ответ был отклонен, но на самом деле может вызвать эту проблему. Благодаря 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, проверьте окно вывода и посмотрите, является ли проблема неустановленной переменной среды.

Ответ 17

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

Ответ 18

Еще один вариант файла не найден, из-за пробелов в пути. В моем случае в msbuild script. Мне нужно было использовать строки 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" />

Ответ 19

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

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

• Ctrl + Alt + O
• Вид > Выход

Ответ 20

Я исправил это, просто перезапустив Visual Studio - я только что запустил dotnet tool install xxx в окне консоли, и VS еще не выбрал новые переменные среды и/или параметры пути, которые были изменены, поэтому быстрый перезапуск решил проблему.

Ответ 21

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

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

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

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

Ответ 22

Для меня это произошло после обновления пакетов 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 и снова открыл его, проблема была исправлена.

Ответ 23

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

Ответ 24

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

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

Ответ 25

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

Ответ 26

По крайней мере, в 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)

Ответ 27

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

Ответ 28

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

Ответ 29

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

Ответ 30

Для меня это была перезагрузка Visual Studio. У меня была построена gulp с кодом 9009. Я установил gulp, но это не отразилось, пока я не перезапустил Visual Studio.