Що означає "вийшов із кодом 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 з Environmental Variables у 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" (Change Directory) у відповідний каталог, перш ніж викликати команду, оскільки виконуваний файл, який я дзвонив, знаходився в моєму каталозі проектів.

Приклад:

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)"

Це вирішило для мене проблему.

Відповідь 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, перевірте вікно виводу та перевірте, чи проблема невстановлена ​​змінна середовище.

Також переконайтесь, що у вікні редагування подій після створення подій у вашому проекті немає розривів рядків. Іноді копіювання команди xcopy з Інтернету, коли вона є багаторядковою та вставлення її у VS, спричинить проблему.

Я додав "> myFile.txt" до кінця рядка на етапі попереднього збирання, а потім перевірив файл на предмет фактичної помилки.

Для мене місце на диску мало, і файли, які не вдалося записати, очікувались, що вони будуть представлені пізніше. Інші відповіді згадували про відсутні файли (або неправильно названі / неправильно посилаються на ім’я файли) - але першопричиною була відсутність місця на диску.

Для мене це сталося після оновлення пакетів нута з однієї версії PostSharp до наступної у великому рішенні (~ 80 проект). У мене є помилки компілятора для проектів, які мають команди в подіях PreBuild.

'cmd' не розпізнається як внутрішня чи зовнішня команда, функціонуюча програма чи пакетний файл. C: \ Program Files (x86) \ MSBuild \ 14.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1249,5): error 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 -> Властивості проекту -> переконайтеся, що ви використовуєте вкладку "Налагодження" (а не вкладку "Події побудови") -> Аргументи командного рядка

Я використав текстову область "Пост / попереднє складання", що було неправильним у цьому випадку.

Моє рішення було просто: як ви намагалися вимкнути його і знову ввімкнути? Тому я перезапустив комп’ютер, і проблеми не було.

Я також зіткнувся з цією 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.

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

Моє рішення полягало в тому, щоб створити копію файлу і додати крок до завдання збірки, щоб скопіювати мій файл над оригіналом.

Вам потрібно переконатися, що ви встановили грунт в усьому світі