O que significa “sair com o código 9009” durante essa compilation?

O que essa mensagem de erro quer dizer? O que eu poderia fazer para corrigir esse problema?

AssemblyInfo.cs saiu com o código 9009


O problema provavelmente está acontecendo como parte de uma etapa de pós-compilation em uma solução .NET no Visual Studio.

Você tentou fornecer o caminho completo do comando que está sendo executado no comando de evento pré ou pós-compilation?

Eu estava recebendo o erro 9009 devido a um comando de evento pós-compilation xcopy no Visual Studio 2008.

O comando "xcopy.exe /YC:\projectpath\project.config C:\compilepath\" saiu com o código 9009.

Mas no meu caso também foi intermitente. Ou seja, a mensagem de erro persiste até o reinício do computador e desaparece após o reinício do computador. Ele está de volta depois de algum problema relacionado remotamente que ainda estou para descobrir.

No entanto, no meu caso, fornecendo o comando com o seu caminho completo resolveu o problema:

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

Em vez de apenas:

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

Se eu não tiver o caminho completo, ele será executado por um tempo após a reboot e, em seguida, será interrompido.

Além disso, como mencionado nos comentários desta postagem, se houver espaços no caminho completo, será necessário colocar aspas em torno do comando . Por exemplo

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

Observe que este exemplo com relação a espaços não é testado.

Isso acontece quando você está faltando algumas configurações de ambiente para usar as ferramentas do Microsoft Visual Studio 2010 x86.
Portanto, tente adicionar como um primeiro comando em suas etapas de pós-compilation:

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

Deve ser colocado antes de qualquer outro comando.
Ele definirá o ambiente para usar as ferramentas do Microsoft Visual Studio 2010 x86.

Código de erro 9009 significa arquivo de erro não encontrado. Todos os motivos subjacentes postados nas respostas aqui são uma boa inspiração para descobrir o motivo, mas o erro em si significa simplesmente um caminho ruim.

Muito provavelmente você tem espaço no seu caminho resultante.

Você pode contornar isso citando os caminhos, permitindo espaços. Por exemplo:

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

Teve a mesma variável depois de alterar a variável PATH de Variáveis ​​Ambientais no Win 7. A alteração para o padrão ajudou.

Eu tive o erro 9009 quando meu script de evento post build estava tentando executar um arquivo em lotes que não existia no caminho especificado.

Se o script realmente faz o que precisa fazer e é apenas o Visual Studio te incomodando sobre o erro, você poderia simplesmente adicionar:

 exit 0 

até o final do seu roteiro.

Eu causei esse erro quando eu redigi minha variável de ambiente Path. Após a edição, acidentalmente adicionei Path= ao início da string do caminho. Com essa variável de caminho malformada, não consegui executar o XCopy na linha de comando (nenhum comando ou arquivo não encontrado) e o Visual Studio se recusou a executar a etapa de pós-compilation, citando erro com o código 9009.

O XCopy geralmente reside em C: \ Windows \ System32. Depois que a variável de ambiente Path permitiu que o XCopy fosse resolvido no prompt do DOS, o Visual Studio criou bem a minha solução.

Verifique a ortografia. Eu estava tentando chamar um executável, mas tinha o nome com erros ortocharts e me deu a exited with code 9009 mensagem de exited with code 9009 .

Meu erro exato foi

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

9009 significa arquivo não encontrado, mas na verdade não conseguiu encontrar a parte “iscc” do comando.

Eu consertei adicionando ";C:\Program Files\Inno Setup 5 (x86)\" à variável de ambiente do sistema "path"

Outra variante:

hoje eu chamo intérprete python do cron no win32 e pegue ExitCode (% ERRORLEVEL%) 9009, porque a conta do sistema usada pelo cron não tem caminho para o diretório Python.

No meu caso eu tive que “CD” (Change Directory) para o diretório correto primeiro, antes de chamar o comando, já que o executável que eu estava chamando estava no diretório do meu projeto.

Exemplo:

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

O problema no meu caso ocorreu quando tentei usar um comando na linha de comando para o evento Post-build em minha biblioteca de classs de teste. Quando você usa aspas assim:

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

ou se você estiver usando o console:

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

Isso resolveu o problema para mim.

Além disso, certifique-se de que não haja quebras de linha na janela de edição de evento pós-compilation no seu projeto. Às vezes, copiar o comando xcopy da Web quando é multi-linha e colá-lo no VS causará um problema.

Eu adicionei “> myFile.txt” ao final da linha na etapa de pré-compilation e, em seguida, inspecionei o arquivo para o erro real.

Para mim, o espaço em disco era baixo e esperava-se que os arquivos que não pudessem ser gravados fossem apresentados posteriormente. Outras respostas mencionaram arquivos ausentes (ou arquivos com nomes incorretos / referenciados incorretamente por nome) – mas a causa raiz foi a falta de espaço em disco.

Ainda outra variante do arquivo não encontrado, por causa dos espaços no caminho. No meu caso no script msbuild. Eu precisava usar o estilo HTML & quot; strings dentro do comando exec.

   

Isso é muito básico, eu tive esse problema, e falha simples embaraçoso.

Uso do aplicativo Argumentos da linha de comando, eu os removi e os adicionei de volta. De repente, o projeto não conseguiu construir.

Visual Studio -> Propriedades do Projeto -> verifique se você usa a aba ‘Debug’ (não aba ‘Build Events’) -> Argumentos da Linha de Comando

Eu usei a área de texto Post e Pre-build, o que estava errado neste caso.

Para mim, aconteceu depois de atualizar pacotes nuget de uma versão PostSharp para a próxima em uma grande solução (projeto ~ 80). Eu tenho erros de compilador para projetos que possuem comandos em events PreBuild.

‘cmd’ não é reconhecido como um comando interno ou externo, programa operável ou arquivo de lote. C: \ Arquivos de Programas (x86) \ MSBuild \ 14.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1249,5): erro MSB3073: O comando “cmd / c C: \ GitRepos \ main \ ServiceInterfaces \ DEV.Config \ PreBuild.cmd ServiceInterfaces “saiu com o código 9009.

A variável PATH foi corrompida, tornando-se muito longa com vários caminhos repetidos relacionados ao PostSharp.Patterns.Diagnostics. Quando fechei o Visual Studio e abri novamente, o problema foi corrigido.

A resposta do tfa foi downvoted, mas na verdade pode causar esse problema. Graças a hanzolo, eu olhei na janela de saída e encontrei o seguinte:

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

Depois de executar o npm install -g gulp , parei de receber esse erro. Se você estiver recebendo esse erro no Visual Studio, verifique a janela de saída e veja se o problema é uma variável de ambiente não definida.

Na verdade, notei que, por alguma razão, a variável de ambiente% windir% às vezes é apagada. O que funcionou para mim foi redefinir a variável de ambiente windir para c: \ windows, reiniciar o VS e pronto. Dessa forma, você evita ter que modificar os arquivos da solução.

Pelo menos no Visual Studio Ultimate 2013, Versão 12.0.30723.00 Atualização 3, não é possível separar uma instrução if / else com uma quebra de linha:

trabalho:

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

não funciona:

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

Ainda outro motivo: Se o seu evento pré-compilation fizer referência a outro caminho bin do projeto e você vir esse erro ao executar o msbuild, mas não o Visual Studio, será necessário organizar manualmente os projetos no arquivo * .sln (com um editor de texto) que o projeto que você está direcionando no evento é construído antes do projeto do evento. Em outras palavras, o msbuild usa a ordem em que os projetos são listados no arquivo * .sln, enquanto o VS usa o conhecimento das dependencies do projeto. Isso aconteceu quando uma ferramenta que cria um database para ser incluído em um wixproj foi listada após o wixproj.

Eu acho que no meu caso havia símbolos russos no caminho (todos os projetos estavam na pasta do usuário). Quando coloquei a solução em outra pasta (diretamente no disco), tudo ficou bem.

Minha solução foi simples: você tentou desligá-lo e ligá-lo novamente? Então eu reiniciei o computador e o problema desapareceu.

O mesmo que as outras respostas, no meu caso, foi por causa do arquivo ausente. Para saber qual é o arquivo ausente, você pode ir para a janela de saída e ele mostrará imediatamente o que faltou.

Para abrir a janela de saída no Visual Studio:

  1. Ctrl + Alt + O
  2. Visualizar> Saída

insira a descrição da imagem aqui

Minha solução foi criar uma cópia do arquivo e adicionar uma etapa à tarefa de compilation para copiar meu arquivo sobre o original.

Eu também corri para este problema 9009 quando enfrenta uma situação de substituição.

Basicamente, se o arquivo já existe e você não especificou a opção /y (que sobrescreve automaticamente) esse erro pode acontecer quando executado a partir de uma construção.

Você precisa ter certeza de que instalou o grunhido globalmente