Выход из команды с кодом 9009 visual studio
Обновлено: 06.07.2024
AssemblyInfo.cs завершился с кодом 9009
Когда я пытаюсь построить VTK на VS 2010, я получаю эту ошибку error MSB6006: cmd.exe exited with code 9009. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets 151 6 vtkhdf5 Перед этим я успешно построил QT из командной строки VS. Мое мнение таково, что с путями.
get topLeft() < return this._topLeft; >set topLeft(value) < this._topLeft = value; Recalc(); >Приведенный выше код работает найти в TypeScript Play, но я получил ошибку сборки при компиляции его из Visual Studio 2012 error exited with code 1 Кто-нибудь пытается получить,установить в TypeScript и.
Вы пытались указать полный путь к команде, которая выполняется в команде события до или после сборки?
Я получал ошибку 9009 из-за команды события xcopy после сборки в Visual Studio 2008.
Команда "xcopy.exe /Y C:\projectpath\project.config C:\compilepath\" вышла с кодом 9009.
Однако в моем случае предоставление команде ее полного пути решило проблему:
Вместо того, чтобы просто:
Если у меня нет полного пути, он работает некоторое время после перезапуска, а затем останавливается.
Обратите внимание, что этот пример в отношении пробелов не тестируется.
Код ошибки 9009 означает, что файл ошибки не найден. Все основные причины, изложенные в ответах здесь, являются хорошим вдохновением для выяснения причин, но сама ошибка просто означает плохой путь.
Это происходит, когда вам не хватает некоторых параметров среды для использования инструментов Microsoft Visual Studio x86.
Поэтому попробуйте добавить в качестве первой команды на этапах после сборки:
Для Visual Studio 2010 использования:
Как упоминалось в комментариях @FlorianKoch, для использования VS 2017 года:
Он должен быть помещен перед любой другой командой.
Он установит среду для использования инструментов Microsoft Visual Studio x86.
Контекст При отладке (с помощью меню отладки F5 ) решения Visual Studio создается процесс под названием MyApp.vshost.exe . Когда вы останавливаете отладку неприлично - я имею в виду использование меню Stop Debug SHIFT + F5 и не ожидание появления строки кода типа Application.Exit() - этот процесс.
Скорее всего, у вас есть пространство на вашем результирующем пути.
Вы можете обойти это, цитируя пути, тем самым позволяя пробелы. Например:
Имел ту же переменную после изменения переменной PATH из переменных среды в Win 7. Возвращение к значению по умолчанию помогло.
У меня была ошибка 9009, когда мой сценарий события post build пытался запустить batch file, который не существовал в указанном пути.
Я вызвал эту ошибку, когда отредактировал переменную окружения Path. После редактирования я случайно добавил Path= в начало строки пути. С такой искаженной переменной path я не смог запустить XCopy в командной строке (ни одна команда или файл не найдены), а Visual Studio отказался выполнить шаг после сборки, сославшись на ошибку с кодом 9009.
XCopy обычно проживает в C:\Windows\System32. После того, как путь переменной среды допускается 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 беспокоит вас об ошибке, вы можете просто добавить:
до конца вашего сценария.
В моем случае я должен был сначала "CD" (изменить каталог) в нужный каталог, прежде чем вызывать команду, так как исполняемый файл, который я вызывал, находился в моем каталоге проекта.
сегодня я вызываю интерпретатор python из cron в win32 и беру ExitCode (%ERRORLEVEL%) 9009, потому что системная учетная запись, используемая cron, не имеет пути к каталогу Python.
Проблема в моем случае возникла, когда я попытался использовать команду в командной строке для события после сборки в моей библиотеке тестовых классов. Когда вы используете кавычки вот так:
или если вы используете консоль:
Это исправило проблему для меня.
ответ tfa был отклонен, но на самом деле может вызвать эту проблему. Благодаря ханзоло я заглянул в окно вывода и обнаружил следующее:
После запуска npm install -g gulp я перестал получать эту ошибку. Если вы получаете эту ошибку в Visual Studio, проверьте окно вывода и посмотрите, является ли проблема неустановленной переменной среды.
Кроме того, убедитесь, что в окне редактирования событий после сборки в вашем проекте нет разрывов строк. Иногда копирование команды xcopy из интернета, когда она многострочная, и вставка ее в VS вызовут проблему.
Я добавил "> myFile.txt " в конец строки на этапе предварительной сборки, а затем проверил файл на наличие фактической ошибки.
Для меня дисковое пространство было низким, и файлы, которые не могли быть записаны, должны были присутствовать позже. В других ответах упоминались отсутствующие файлы (или неправильно названные/неправильно referenced-by-name файлов), но основной причиной была нехватка дискового пространства.
Как и другие ответы, в моем случае это было из-за пропавшего файла. Чтобы узнать, что такое пропавший файл, вы можете перейти в окно вывода, и оно сразу же покажет вам, что пропало.
Чтобы открыть окно вывода в Visual Studio:
Еще один вариант файла не найден, из-за пробелов в пути. В моем случае в сценарии msbuild. Мне нужно было использовать строки HTML style " в команде exec.
Для меня это произошло после обновления пакетов nuget с одной версии PostSharp на следующую в большом решении (
80 проектов). У меня есть ошибки компилятора для проектов, в которых есть команды в событиях PreBuild.
'cmd' не распознается как внутренняя или внешняя команда, действующая программа или batch file. 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 - я только что запустил dotnet tool install xxx в окне консоли, а VS еще не подобрал новые переменные среды и/или параметры пути, которые были изменены, поэтому быстрый перезапуск исправил проблему.
Это довольно просто, у меня была такая проблема, и смущающая простая неудача.
Приложение использует аргументы командной строки, я удалил их, а затем добавил обратно. Внезапно проект не удалось построить.
Visual Studio -> свойства проекта - > убедитесь, что вы используете вкладку 'Debug' (а не вкладку 'Build Events') - > аргументы командной строки
Я использовал текстовую область and Post/Pre-build, что в данном случае было неправильно.
Мое решение было просто: вы пробовали выключать и включать его снова? Поэтому я перезагрузил компьютер, и проблема исчезла.
Я также столкнулся с этой проблемой 9009 , столкнувшись с ситуацией перезаписи.
В принципе, если файл уже существует и вы не указали переключатель /y (который автоматически перезаписывается), эта ошибка может произойти при запуске из сборки.
У меня была та же ошибка, вызванная моим сценарием post build, и я попытался запустить сценарий строка за строкой в командной строке. Наконец я выяснил, что основная причина заключается в том, что я не заполнил недостающую информацию в файле .nuspec, то есть заменил все переменные между $ и $ фактическим значением, например, заменил $author$ своим именем
Похожие вопросы:
Я получаю Compilation exited with code 134 при попытке использовать переключатель LLVM Optimizing Compiler для сборки release iPhone, используя MonoTouch 4.0.1. Я вообще не получаю много информации.
Есть ли хороший способ отладить ошибку времени выполнения exited with code 5 на симуляторе iPhone? Я знаю, что это должен быть настоящий вопрос NOOB, но любые советы будут оценены по достоинству.
Когда я пытаюсь построить VTK на VS 2010, я получаю эту ошибку error MSB6006: cmd.exe exited with code 9009. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets 151 6.
get topLeft() < return this._topLeft; >set topLeft(value) < this._topLeft = value; Recalc(); >Приведенный выше код работает найти в TypeScript Play, но я получил ошибку сборки при компиляции его.
Контекст При отладке (с помощью меню отладки F5 ) решения Visual Studio создается процесс под названием MyApp.vshost.exe . Когда вы останавливаете отладку неприлично - я имею в виду использование.
Почему gdb показывает, что программа вышла во время своего запуска, поэтому прежде чем остановиться на первой точке останова в основной функции ? Некоторые действия: $ gdb --cd $programhome -tui.
Недавно я обновил свой Visual Studio 2015 до 2017 года, а затем попытался перенести все свои решения с VS2015. Но после миграции одна из моих сборок проекта потерпела неудачу с приведенной ниже.
AssemblyInfo.cs вышел с кодом 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.
Однако, в моем случае, при условии, что команда с полным пути решена, проблема:
Если у меня нет полного пути, он запускается некоторое время после перезапуска, а затем останавливается.
Обратите внимание, что этот пример в отношении пробелов не проверен.
Ответ 2
Код ошибки 9009 означает, что файл ошибки не найден. Все основные причины, изложенные в ответах здесь, являются хорошим источником, чтобы понять, почему, но сама ошибка просто означает плохой путь.
Ответ 3
Это происходит, когда вам не хватает некоторых параметров среды для использования инструментов Microsoft Visual Studio x86.
Поэтому попробуйте добавить в качестве первой команды на этапах после сборки:
Для Visual Studio 2010 используйте:
Как уже упоминалось в комментариях @FlorianKoch, для VS 2017 используйте:
Его следует поместить перед любой другой командой.
Он установит среду для использования инструментов Microsoft Visual Studio x86.
Ответ 4
Скорее всего, у вас есть место в результирующем пути.
Вы можете обойти это, указав пути, тем самым позволяя пробелы. Например:
Ответ 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.
Ответ 9
Ответ 10
В моем случае перед вызовом команды мне пришлось сначала записать "CD" ( "Изменить каталог" ) в соответствующий каталог, поскольку исполняемый файл, который я вызывал, был в моей директории проектов.
Ответ 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 в моей тестовой библиотеке классов. Когда вы используете такие кавычки:
или если вы используете консоль:
Это исправило проблему для меня.
Ответ 14
Кроме того, убедитесь, что в окне редактирования событий post build в вашем проекте нет разрывов строк. Иногда копирование команды xcopy из сети, когда она многострочная и вставляет ее в VS, вызовет проблему.
Ответ 15
Я добавил " > myFile.txt" в конец строки на этапе предварительной сборки, а затем проверил файл на фактическую ошибку.
Ответ 16
Тфа ответ был отклонен, но на самом деле может вызвать эту проблему. Благодаря hanzolo я посмотрел в окне вывода и нашел следующее:
После запуска npm install -g gulp я перестал получать эту ошибку. Если вы получаете эту ошибку в Visual Studio, проверьте окно вывода и посмотрите, является ли проблема неустановленной переменной среды.
Ответ 17
Для меня дисковое пространство было низким, и ожидается, что файлы, которые не могут быть записаны, будут представлены позже. В других ответах упоминались недостающие файлы (или неправильно названные/неправильные ссылки на файлы), но основной причиной было отсутствие дискового пространства.
Ответ 18
Еще один вариант файла не найден, из-за пробелов в пути. В моем случае в msbuild script. Мне нужно было использовать строки HTML и ampquot; в команде exec.
Ответ 19
То же, что и другие ответы, в моем случае это было из-за недостающего файла. Чтобы узнать, что является отсутствующим файлом, вы можете перейти в окно вывода, и он сразу покажет вам, что пропало.
Чтобы открыть окно вывода в Visual Studio:
Ответ 20
Я исправил это, просто перезапустив Visual Studio - я только что запустил dotnet tool install xxx в окне консоли, и VS еще не выбрал новые переменные среды и/или параметры пути, которые были изменены, поэтому быстрый перезапуск решил проблему.
Ответ 21
Это довольно просто, я столкнулся с этой проблемой и смущающе провалился.
Приложение использует аргументы командной строки, я удалил их, а затем добавил их обратно. Вдруг проект не смог построить.
Я использовал текстовую область 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 с разрывом строки:
Ответ 27
Еще одна причина: Если ваше событие pre-build ссылается на другой путь к bin файлам, и вы видите эту ошибку при запуске msbuild, но не Visual Studio, тогда вам нужно вручную организовать проекты в файле *.sln(с текстовым редактором), чтобы проект нацелены на событие, которое создается перед проектом события. Другими словами, msbuild использует порядок, в котором проекты перечислены в файле *.sln, тогда как VS использует знания зависимостей проекта. Это произошло, когда инструмент, который создает базу данных, которая будет включена в wixproj, была указана после wixproj.
Ответ 28
Я думаю, что в моем случае были русские символы в пути (все проекты были в папке пользователя). Когда я помещал решение в другую папку (прямо на диск), все стало нормально.
Ответ 29
Мое решение состояло в том, чтобы создать копию файла и добавить шаг к заданию сборки, чтобы скопировать мой файл поверх оригинала.
Ответ 30
Для меня это была перезагрузка Visual Studio. У меня была построена gulp с кодом 9009. Я установил gulp, но это не отразилось, пока я не перезапустил Visual Studio.
AssemblyInfo.cs вышел с кодом 9009
Вы пытались указать полный путь к команде, которая выполняется в команде события до или после сборки?
Я получал ошибку 9009 из-за команды события xcopy post-build в Visual Studio 2008.
Команда "xcopy.exe /Y C:\projectpath\project.config C:\compilepath\" вышла с кодом 9009.
Однако в моем случае указание полного пути к команде решило проблему:
Если у меня нет полного пути, он запускается некоторое время после перезапуска, а затем останавливается.
Обратите внимание, что этот пример с пробелами не тестировался.
Код ошибки 9009 означает, что файл ошибки не найден. Все причины, приведенные в ответах, являются хорошим источником вдохновения, чтобы выяснить, почему, но сама ошибка просто означает неверный путь.
Это происходит, когда вам не хватает некоторых параметров среды для использования инструментов Microsoft Visual Studio 2010 x86.
Поэтому попробуйте добавить в качестве первой команды на этапах после сборки:
Это должно быть помещено перед любой другой командой.
Это установит среду для использования инструментов Microsoft Visual Studio 2010 x86.
Скорее всего, у вас есть место на вашем пути следования.
Вы можете обойти это, указав пути, тем самым оставляя пробелы. Например:
Была такая же переменная после изменения переменной PATH из переменных среды в Win 7. Помогло возвращение к стандартному.
У меня была ошибка 9009, когда мой сценарий событий после сборки пытался запустить пакетный файл, который не существовал по указанному пути.
Я вызвал эту ошибку, когда отредактировал переменную окружения Path. После редактирования я случайно добавил Path= в начало строки пути. С такой неверно сформированной переменной пути мне не удалось запустить XCopy в командной строке (команда или файл не найдены), а Visual Studio отказалась выполнить шаг после сборки, сославшись на ошибку с кодом 9009.
XCopy обычно находится в C:\Windows\System32. Как только переменная среды Path позволила разрешить XCopy в DOS Prompt, Visual Studio хорошо построила мое решение.
Если скрипт действительно выполняет то, что ему нужно, и он просто выдает ошибку об ошибке, которую вы можете просто добавить:
в конце вашего сценария.
В моем случае мне пришлось сначала "CD" (сменить каталог) в нужный каталог, прежде чем вызывать команду, так как вызываемый файл находился в каталоге моего проекта.
4 Установите серверы Xampp и Wamp для запуска файлов PHP
AssemblyInfo.cs завершился с кодом 9009
Вы пытались указать полный путь к команде, которая выполняется в команде события до или после сборки?
Я получал ошибку 9009 из-за xcopy команда события post-build в Visual Studio 2008.
Команда 'xcopy.exe /Y C:\projectpath\project.config C:\compilepath\' вышел с кодом 9009.
Однако в моем случае предоставление команды с полным путем решило проблему:
Вместо того, чтобы просто:
Если у меня нет полного пути, он работает некоторое время после перезапуска, а затем останавливается.
Обратите внимание, что этот пример относительно пробелов не тестировался.
Код ошибки 9009 означает, что файл ошибки не найден. Все основные причины, указанные в ответах здесь, служат хорошим вдохновением для выяснения причины, но сама ошибка просто означает неправильный путь.
- 1 Моя проблема с не найденным файлом заключалась в том, что ссылка в файле csproj была $ (PROGRAMFILES) \ Microsoft SDKs \ TypeScript \ tsc и должна была быть $ (PROGRAMFILES) \ Microsoft SDKs \ TypeScript \ 1.0 \ tsc
- Спасибо, что ответили на первый вопрос.
- И это означает, что не удалось найти ни одного файла, в котором может быть задействована попытка выполнения команды, даже если она не смогла найти саму команду. Я использовал delete вместо del. Это тоже даст вам 9009.
Это случается, когда вам не хватает некоторых настроек среды для использования инструментов Microsoft Visual Studio x86.
Поэтому попробуйте добавить в качестве первой команды на этапах после сборки:
Для Visual Studio 2010 используйте:
Как упоминал @FlorianKoch в комментариях, для VS 2017 используйте:
Его следует размещать перед любой другой командой.
Он установит среду для использования инструментов Microsoft Visual Studio x86.
Скорее всего, у вас есть место на вашем результирующем пути.
Вы можете обойти это, указав пути, таким образом, оставив пробелы. Например:
Была такая же переменная после изменения переменной 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'
до конца вашего сценария.
- 5.Нельзя скрывать любую потенциальную ошибку
- 1 Я согласен, это не должно маскироваться
- 1 К этому добавьте проверку наличия исполняемого файла в вашей системе вообще.
- 1 Это устранило проблему с запуском devenv.exe из Visual Studio, но вам не нужно указывать папку во второй раз, просто вызовите build.bat.
сегодня я вызываю интерпретатор python из cron в win32 и беру ExitCode (% ERRORLEVEL%) 9009, потому что системная учетная запись, используемая cron, не имеет пути к каталогу Python.
Проблема в моем случае возникла, когда я попытался использовать команду в командной строке для события Post-build в моей библиотеке тестовых классов. Когда вы используете такие кавычки:
или если вы используете консоль:
Это устранило проблему для меня.
Ответ tfa был отклонен, но на самом деле может вызвать эту проблему. Благодаря hanzolo я заглянул в окно вывода и обнаружил следующее:
После запуска npm install -g gulp , Я перестал получать эту ошибку. Если вы получаете эту ошибку в Visual Studio, проверьте окно вывода и посмотрите, не связана ли проблема с неустановленной переменной среды.
Кроме того, убедитесь, что в окне редактирования события пост-сборки в вашем проекте нет разрывов строк. Иногда копирование команды xcopy из Интернета, когда она многострочная, и вставка ее в VS вызывает проблемы.
- Хотя jesse хорошо замечает, что в середине команды xcopy не должно быть разрывов строк, обратите внимание, что в общем случае допустимы разрывы строк в этом поле; каждую строку следует интерпретировать как отдельную команду.
Я добавил "> myFile.txt" в конец строки на этапе предварительной сборки, а затем проверил файл на предмет фактической ошибки.
Для меня места на диске было мало, и файлы, которые нельзя было записать, должны были появиться позже. В других ответах упоминались отсутствующие файлы (или файлы с неверным именем / неправильной ссылкой по имени), но основной причиной была нехватка места на диске.
Для меня это произошло после обновления пакетов nuget с одной версии PostSharp до следующей в большом решении (проект
80). У меня есть ошибки компилятора для проектов, в которых есть команды в событиях PreBuild.
Переменная PATH была повреждена, становясь слишком длинной, с несколькими повторяющимися путями, связанными с PostSharp.Patterns.Diagnostics. Когда я закрыл Visual Studio и снова открыл ее, проблема была устранена.
Еще один вариант файла не найден из-за пробелов в пути. В моем случае в скрипте msbuild. Мне нужно было использовать стиль HTML & ampquot; строки в команде exec.
Как и другие ответы, в моем случае это было из-за отсутствующего файла. Чтобы узнать, что это за файл, вы можете перейти в окно вывода, и оно сразу покажет вам, что пропало.
Чтобы открыть окно вывода в Visual Studio:
Я исправил это, просто перезапустив Visual Studio - я только что запустил <?php dotnet tool install xxx в окне консоли, а VS еще не подобрал новые переменные среды и / или настройки пути, которые были изменены, поэтому быстрый перезапуск устранил проблему.
Это довольно просто, у меня была эта проблема и досадный простой провал.
Приложение использует аргументы командной строки, я удалил их, а затем добавил обратно. Вдруг проект не удалось построить.
Я использовал текстовую область и Post / Pre-build, что в данном случае было неправильным.
Мое решение было простым: вы пробовали выключить и снова включить? Поэтому я перезагрузил компьютер, и проблема исчезла.
Я тоже столкнулся с этим 9009 проблема при перезаписи.
Обычно, если файл уже существует, и вы не указали /y switch (который автоматически перезаписывает), эта ошибка может возникнуть при запуске из сборки.
У меня была такая же ошибка, вызванная моим сценарием пост-сборки, и я попытался запустить сценарий построчно в командной строке. Наконец, я выяснил, что основная причина в том, что я не заполнил недостающую информацию в файле .nuspec, т.е. заменил все переменные между $ и $ фактическим значением, например заменив $ author $ моим именем
На самом деле я заметил, что по какой-то причине переменная окружения% windir% иногда стирается. Что сработало для меня, так это переустановить переменную среды windir на c: \ windows, перезапустить VS и все. Таким образом вы избавитесь от необходимости изменять файлы решения.
По крайней мере, в Visual Studio Ultimate 2013 версии 12.0.30723.00 с обновлением 3 невозможно разделить оператор if / else разрывом строки:
Еще одна причина: если ваше событие перед сборкой ссылается на другой путь к корзине проектов, и вы видите эту ошибку при запуске msbuild, но не Visual Studio, то вам необходимо вручную упорядочить проекты в файле * .sln (с помощью текстового редактора), чтобы что проект, на который вы нацеливаетесь в событии, построен до проекта события. Другими словами, msbuild использует порядок, в котором проекты перечислены в файле * .sln, тогда как VS использует информацию о зависимостях проекта. У меня это случилось, когда инструмент, который создает базу данных для включения в wixproj, был указан после wixproj.
Думаю, в моем случае в пути были русские символы (все проекты находились в папке пользователя). Когда я поместил раствор в другую папку (прямо на диск), все стало нормально.
Мое решение состояло в том, чтобы создать копию файла и добавить шаг к задаче сборки, чтобы скопировать мой файл поверх оригинала.
Читайте также: