O que significa "encerrado com o código 9009" durante essa compilação?

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 pós-compilação em uma solução .NET no Visual Studio.

Você tentou fornecer o caminho completo do comando que está sendo executado no comando de evento anterior ou posterior à compilação?

Eu estava recebendo o erro 9009 devido a um xcopycomando de evento pós-compilação no Visual Studio 2008.

O comando "xcopy.exe /Y C:\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é a reinicialização do computador e desaparece após a reinicialização do computador. Está de volta depois de algum problema remotamente relacionado que ainda estou para descobrir.

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

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

Em vez de apenas:

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

Se eu não tiver o caminho completo, ele será executado por um tempo após uma reinicialização e depois será interrompido.

Também como mencionado nos comentários a esta postagem, se houver espaços no caminho completo, será necessário aspas ao redor do comando . Por exemplo

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

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

Código de erro 9009 significa arquivo de erro não encontrado. Todas as razões subjacentes postadas nas respostas aqui são uma boa inspiração para descobrir o porquê, mas o próprio erro simplesmente significa um caminho ruim.

Isso acontece quando faltam algumas configurações de ambiente para o uso das ferramentas do Microsoft Visual Studio x86.
Portanto, tente adicionar como primeiro comando nas etapas pós-compilação:

Para o Visual Studio 2010, use:

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

Como o @FlorianKoch mencionado nos comentários, para o VS 2017, use:

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

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

Provavelmente você tem espaço no 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

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

Eu tive o erro 9009 quando meu script de evento pós-compilação estava tentando executar um arquivo em lotes que não existia no caminho especificado.

Causei esse erro quando redigitei minha variável de ambiente Path. Após a edição, adicionei acidentalmentePath= o início da string do caminho. Com uma variável de caminho malformada, não consegui executar o XCopy na linha de comando (nenhum comando ou arquivo não foi encontrado) e o Visual Studio se recusou a executar a etapa pós-compilação, citando erro no 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 minha solução.

Meu erro exato foi

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

9009 significa que o arquivo não foi encontrado, mas na verdade não foi possível encontrar a parte "iscc" do comando.

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

Se o script realmente faz o que precisa ser feito e o Visual Studio está incomodando o erro, você pode adicionar:

exit 0

até o final do seu script.

Verifique a ortografia. Eu estava tentando chamar um executável, mas o nome estava incorreto e ele me deu a exited with code 9009mensagem.

No meu caso, eu tive que "CD" (Alterar diretório) primeiro no diretório apropriado, antes de chamar o comando, pois o executável que eu estava chamando estava no diretório do projeto.

Exemplo:

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

Outra variante:

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

O problema no meu caso ocorreu quando tentei usar um comando na linha de comando para o evento Pós-compilação na minha Biblioteca de Classes de Teste. Quando você usa aspas da seguinte forma:

"$(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 corrigiu o problema para mim.

A resposta da tfa foi reduzida, mas na verdade pode causar esse problema. Graças ao hanzolo, procurei 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\<filepath>\Web.csproj(4,5): error MSB3073: The command "gulp clean" exited with code 9009.

Depois de executar 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.

Além disso, verifique se não há quebras de linha na janela de edição do evento pós-compilação no seu projeto. Às vezes, copiar o comando xcopy da Web quando estiver com várias linhas e colá-lo no VS causará um problema.

Eu adicionei "> myFile.txt" ao final da linha na etapa de pré-compilação e, em seguida, inspecionei o arquivo quanto ao erro real.

Para mim, o espaço em disco era baixo e os arquivos que não podiam ser gravados deveriam estar presentes mais tarde. Outras respostas mencionaram arquivos ausentes (ou arquivos com nomes incorretos / incorretamente referenciados por nome) - mas a causa principal foi a falta de espaço em disco.

Para mim, aconteceu após a atualização dos pacotes de nuget de uma versão do PostSharp para a próxima em uma grande solução (projeto ~ 80). Eu tenho erros de compilador para projetos que possuem comandos nos eventos do PreBuild.

'cmd' não é reconhecido como um comando interno ou externo, programa operável ou arquivo em 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 "encerrado 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 o abri novamente, o problema foi corrigido.

Ainda outra variante do arquivo não encontrada, devido aos espaços no caminho. No meu caso, no script msbuild. Eu precisava usar o estilo HTML & quot; cadeias dentro do comando 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" />

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 ela mostrará imediatamente o que está faltando.

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

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

Corrigi isso simplesmente reiniciando o Visual Studio - eu tinha acabado de executar dotnet tool install xxxem uma janela do console e o VS ainda não havia capturado as novas variáveis ​​de ambiente e / ou configurações de caminho que foram alteradas; portanto, uma reinicialização rápida corrigiu o problema.

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

O aplicativo usa argumentos de linha de comando, eu os removi e os adicionei novamente. De repente, o projeto falhou na construção.

Visual Studio -> Propriedades do projeto -> verifique se você usa a guia 'Debug' (não a guia 'Build Events') -> argumentos da linha de comando

Usei a área de texto Post / Pre-build, que estava errada neste caso.

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

Também encontrei esse 9009problema ao enfrentar uma situação de substituição.

Basicamente, se o arquivo já existe e você não especificou a /yopção (que substitui automaticamente), esse erro pode ocorrer quando executado a partir de uma compilação.

Na verdade, notei que, por algum motivo, a variável de ambiente% windir% às vezes é apagada. O que funcionou para mim foi redefinir a variável de ambiente windir como c: \ windows, reiniciar o VS e é isso. Dessa forma, você evita a necessidade de 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)

Outro motivo: se o evento de pré-compilação referenciar outro caminho da bandeja de projetos 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) para que que o projeto que você está direcionando no evento é criado 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 dependências do projeto. Isso aconteceu quando uma ferramenta que cria um banco de dados para ser incluído em um wixproj foi listada após o wixproj.

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 criar uma cópia do arquivo e adicionar uma etapa à tarefa de compilação para copiar meu arquivo sobre o original.

Você precisa se certificar de ter instalado o grunhido globalmente