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

Что означает это сообщение об ошибке? Что я мог сделать, чтобы исправить эту проблему?

AssemblyInfo.cs вышел с кодом 9009

Проблема, вероятно, возникает как часть шага после сборки в решении .NET в Visual Studio.

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

Я получал ошибку 9009 из-за xcopyкоманды события после сборки в 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\

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

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

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

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

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

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

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

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

Скорее всего, у вас есть место на вашем пути следования.

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

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

Была такая же переменная после изменения переменной PATH из переменных среды в Win 7. Помогло возвращение к стандартному.

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

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

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

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

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

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

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

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

exit 0

в конце вашего сценария.

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

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

Пример:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

работает:

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

не работает:

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

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

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

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

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