Cópia de comando encerrada com o código 4 ao criar - a reinicialização do Visual Studio resolve

De vez em quando, quando construo minha solução aqui (com 7 projetos), recebo o temido erro 'Cópia de comando encerrada com código 4', no Visual Studio 2010 Premium ed.

Isso ocorre porque o evento pós-construção não pode ser executado.

Aqui está o que resolve o problema, temporariamente

• Às vezes: uma reinicialização do Visual Studio e eu consigo criar a solução
• Às vezes: a reinicialização do Visual Studio e meu gerenciador de arquivos preferido (Q-Dir 4.37) o solucionam.

Veja como é o evento pós-compilação:

xcopy "$(SolutionDir)Solution Items\References\*.dll" "$(TargetDir)" /Y

Quando você obtém a cópia de comando encerrada com o erro de código [inserir valor], normalmente isso ocorre devido ao seguinte:

• permissões de leitura / gravação
• arquivos ausentes
• diretórios errados

No entanto - obviamente, quando eu construo a solução, não há problema.

FYI, eu desinstalei o ReSharper 5.1.1 há duas semanas e o Visual Studio me deu alguns erros desde então (entre eles, não é possível depurar). Reinstalei o Visual Studio e ele está funcionando melhor desde então, mas ainda há esse problema. Poderia ter a ver com algumas coisas do ReSharper em algum lugar?

Você já teve o mesmo problema e resolveu? Ou você tem alguma solução possível para isso?

Eu sempre achei isso um problema de bloqueio de arquivos. O código 4 não pode acessar o arquivo. Uma solução parcial que encontrei é usar a opção / C para xcopy (que continua com erro). Não é realmente uma solução, mas principalmente impediu que minhas compilações falhassem.

Outra solução que funciona apenas em 32 bits é usar a ferramenta unlocker para liberar os identificadores do Windows no arquivo antes da cópia.

Edit: Acabei de perceber que ele também funciona com menos de 64 bits.

Embora /Cpossa ignorar erros, pode não ser a solução real, pois pode haver arquivos que DEVEM ser copiados para que a compilação seja bem-sucedida.

O problema mais comum são as aspas ausentes nas tags de comando predefinidas (como $TargetDir). Quando se cria várias ramificações e caminhos no código ou no TFS, há uma chance muito alta de que isso ocorra.

Às vezes, se o arquivo for somente leitura, ele também causará problemas. Adicione a /Ropção para permitir que arquivos somente leitura sejam copiados. Você pode encontrar uma lista de opções disponíveis em:

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/xcopy.mspx?mfr=true

Outro possível problema é que a pasta subjacente não pode ser acessada. Se sim, tente executar em "start xcopy"vez de "xcopy". Isso abrirá outra janela de comando, mas com privilégios de administrador.

Cruzei o mesmo erro, mas não é porque o arquivo está bloqueado, mas o arquivo está ausente.

A razão pela qual o VS tentou copiar um arquivo não existente é por causa do comando de evento Pós-compilação.

Depois que resolvi isso, o problema foi resolvido.

ATUALIZAR:

Como comentou @rhughes:

O verdadeiro problema é como obter o comando aqui para funcionar, em vez de removê-lo.

e ele está absolutamente certo.

Eu também enfrentei esse problema. Verifique o resultado na janela de erro.

No meu caso, um rejeito \estava travando o xcopy (como eu estava usando $(TargetDir)). No meu caso $(SolutionDir)..\bin. Se você estiver usando outra saída, isso precisa ser ajustado.

Observe também que start xcopynão o corrige, se o erro desaparecer após a compilação. Pode ter sido suprimido pela linha de comando e nenhum arquivo foi realmente copiado!

Você pode executar manualmente seus comandos xcopy em um shell de comando. Você obterá mais detalhes ao executá-los lá, apontando você na direção certa.

Caso o evento de pós-construção contenha o comando copy / xcopy para copiar a saída de compilação para algum diretório (que geralmente é a operação mais comum de pós-compilação), o problema poderá ocorrer se o caminho completo do diretório dos destinos de origem ou de destino contiver nomes de pastas que incluem espaços. Remova espaço para o (s) nome (s) do diretório e tente.

Como mencionado em muitos sites, existem várias razões para isso. Para mim, foi devido ao comprimento da Origem e Destino (comprimento do caminho). Eu tentei o xcopy no prompt de comando e não consegui digitar a fonte e o caminho completos (após alguns caracteres, ele não permitirá que você digite). Reduzi o comprimento do caminho e pude executar. Espero que isto ajude.

Execute o VS no modo Administrador e deve funcionar bem.

Eu recebi esse erro porque a conta de usuário em que o Serviço de Compilação do TFS estava sendo executado não tinha permissão para gravar na pasta de destino. Right-click on the folder-->Properties-->Security.

Isso pode acontecer em vários casos:

1. Quando o caminho completo da string tiver mais de 254 caracteres.
2. Quando o nome do arquivo a ser copiado está errado.
3. Quando o caminho de destino está errado.
4. Quando o atributo somente leitura é definido no arquivo copiado ou na pasta de destino.

Eu recebi esse erro porque o arquivo foi aberto em outra instância.

Quando fechei o arquivo e recriei novamente a solução, ela foi copiada com êxito.

Eu enfrentei o mesmo problema no caso do XCOPY após a conclusão da compilação. No meu caso, o problema estava acontecendo por causa das permissões somente leitura definidas nas pastas.

Adicionei o comando attrib -R antes do XCOPY e ele resolveu o problema.

Espero que ajude alguém!

Eu tive o mesmo erro com o xcopy em conexão com o mecanismo de teste. Estou usando o VisualStudio Professional 2013. Por padrão Teste -> Configurações de teste -> Manter o mecanismo de execução de teste em execução parece ser o motivo do meu código de erro 4 com o xcopy. Desligá-lo resolveu o problema. O mecanismo de execução parece manter algumas DLLs.

Eu tive o mesmo problema. Uma simples 'Solução Limpa' no VS limpou o erro, mas era uma solução temporária.

Descobri que definir o parâmetro Copiar para Diretório de Saída em Copiar sempre parece ter resolvido o problema de bloqueio. Embora agora eu tenha 2 cópias dos arquivos e precise excluir um.

Eu tive o mesmo problema. No entanto, nada funcionou para mim. Eu resolvi o problema adicionando

exit 0

ao meu código. O problema era que, enquanto eu estava copiando os arquivos, às vezes o último arquivo não era encontrado e o bastão retornava um valor diferente de zero.

Espero que isso ajude alguém!

Se você estiver executando o Windows 7 em diante, poderá tentar o novo comando 'robocopy':

robocopy "$(SolutionDir)Solution Items\References\*.dll" "$(TargetDir)"

Mais informações sobre robocopy podem ser encontradas aqui .

Eu enfrentei o mesmo problema. Excluí eventos pós-compilação e ele começou a funcionar. Algumas vezes, quando adicionamos alguns componentes SQL, também podemos adicionar comandos pós-compilação.

Estou recebendo algo semelhante usando um xcopy com a opção / exclude. No meu caso, descobri que editar o evento pós-compilação (algo inofensivo como uma nova linha após o comando) e salvar o projeto causa o erro. Salvar novamente o arquivo especificado na opção / excluir faz com que ele funcione novamente.

Enquanto escrevo uma biblioteca DLL, usei o comando xcopy para copiar a biblioteca onde o programa pode encontrá-lo e carregá-lo. Depois de várias vezes abrindo e fechando o programa, ainda havia um processo aberto no gerenciador de tarefas que eu não reconhecia.

Procure por qualquer processo do qual o arquivo possa ser usado e feche-o.

O que foi corrigido para mim : procure a solução específica para o projeto que você deseja, ou seja, NÃO o arquivo geral da solução para todos os projetos.

Tente - tentei tudo o mais mencionado aqui, mas sem sucesso.

Não vejo nada aqui para sugerir que este é um aplicativo da web, mas eu mesmo tive esse problema - tenho dois comandos xcopy em um evento pós-compilação e apenas um deles estava falhando. Algo tinha um bloqueio no arquivo e não era o Visual Studio (como tentei reiniciá-lo).

A única outra coisa que teria usado a dll que eu construí era o IIS. E eis que eis

Um simples iisresetfez o truque para mim.

Eu tive o mesmo problema. Isso foi causado por ter o mesmo sinalizador duas vezes, por exemplo:

if $ (ConfigurationName) == Release (xcopy "$ (TargetDir) . " "$ (SolutionDir) Implantação \ $ (ProjectName) \" / e / d / i / y / e)

Observe que o sinalizador "/ e" aparece duas vezes. A remoção da duplicata resolveu o problema.

No meu caso, $(OutDir)era simplesmente ..\..\Build\um caminho relativo. E, quando eu estava tentando xcopy da seguinte maneira xcopy /y "$(OutDir)Proj1.dll" "Anypath\anyfolder\", estava recebendo o erro do código de saída 4.

O que estava acontecendo era que esse comando estava sendo executado no próprio $ (OutDir) (na minha pasta de compilação) e não no diretório em que o arquivo csproj do projeto estava localizado (como seria de se esperar). Por isso, eu continuei recebendoFile not found erro (correspondente ao código de saída 4).

Eu não conseguia descobrir isso até escrever cdnos eventos Post Build, para imprimir em qual diretório isso estava sendo executado.

Portanto, para resumir, se quisermos copy/ xcopyarquivos do $(OutDir), use "$(TargetDir)"(que é o caminho completo para o diretório de saída) ou não precise especificar nenhum caminho.

Pode ser causado pela estação de trabalho VMWare com pastas compartilhadas

Eu sempre tenho o problema quando a pasta de destino do xcopy também é mapeada como Pasta Compartilhada em uma VM.

Eu o resolvi com um script em execução na vm e excluindo o conteúdo da pasta compartilhada.

Para expandir a resposta de rhughes,

A robocópia funciona perfeitamente, caso você precise incluir subdiretórios que você pode usar /epara incluir subs e copiar diretórios vazios ou /spara incluir subs excluindo diretórios vazios.

A robocopy também relatará algumas coisas, como se novos arquivos foram copiados, isso fará com que o VS reclame, pois qualquer coisa acima de 0 é uma falha e a robocopy retornará 1 se novos arquivos forem encontrados. Vale ressaltar que a robocópia compara primeiro o Source / Dest e copia apenas os arquivos atualizados / novos.

Para contornar esse uso:

(robocopy "$(SolutionDir)Solution Items\References\*.dll" "$(TargetDir)") ^& IF %ERRORLEVEL% LEQ 4 exit /B 0

Se você está aqui porque seu projeto falha ao construir em um servidor de compilação, mas cria bem "manualmente" em uma máquina de desenvolvimento, e você está fazendo xcopyapenas para depuração e emulação de um ambiente de produção em uma máquina de desenvolvimento, convém procurar nesta solução:

https://stackoverflow.com/a/1732478/2279059

Você simplesmente desativa os eventos pós-compilação no servidor de compilação usando

msbuild foo.sln /p:PostBuildEvent=

Isso não é bom o suficiente se você tiver outros eventos pós-compilação que também precisam ser executados no servidor de compilação e não for uma solução geral. No entanto, como existem muitas causas diferentes desse problema, não pode haver uma solução geral. Uma das muitas respostas para essa pergunta (e suas duplicatas) provavelmente ajudará, mas tenha cuidado com abordagens que apenas contornem o tratamento de erros (como xcopy /C). Isso pode funcionar para você, especialmente também no cenário do servidor de compilação, mas acho que esse é mais confiável, se puder ser usado.

Também foi sugerido que, nas versões mais recentes do Visual Studio, o problema não existe mais, portanto, se você estiver usando uma versão antiga, considere atualizar suas ferramentas de compilação.

O código de erro 4 pode significar muitas coisas, por isso recomendo a leitura das outras respostas até encontrar uma solução que funcione para você E você entender POR QUE funciona (algumas soluções desativam o tratamento de erros, o que pode mascarar o problema, mas não resolvê-lo).

Esse pode ser um problema de bloqueio de arquivo relacionado à construção paralela. Uma solução alternativa é não usar a construção paralela. Esse é o comportamento padrão, mas se você estiver usando a -mopção, os projetos serão construídos em paralelo. As seguintes variações não devem criar projetos em paralelo, para que você não encontre o problema de bloqueio de arquivo.

msbuild -m:1
msbuild -maxcpucount:1
msbuild

Observe que, ao contrário do que foi dito aqui, isso acontece até com a versão "mais recente" do MSBuild (a partir de Build Tools for Visual Studio 2019).

A melhor solução é provavelmente garantir que você não precise copiar arquivos em uma etapa pós-compilação. Em algumas situações, você também pode desativar as etapas pós-compilação ao criar com o MSBuild em um servidor de compilação: https://stackoverflow.com/a/55899347/2279059