vantagens - Cópia de comando encerrada com o código 4 ao compilar-o reinício do Visual Studio resolve




visual studio code vantagens (17)

Caso o evento post build contenha o comando copy / xcopy para copiar a saída de compilação em algum diretório (que geralmente é a operação mais comum de compilação), o problema pode ocorrer caso o caminho completo do diretório de destinos de origem ou destino contenha nomes de pastas que incluam espaços. Remova o espaço para o (s) nome (s) do diretório e tente.

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

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

Aqui está o que resolve o problema, temporariamente

  • Às vezes: um reinício do Visual Studio e sou capaz de construir a solução
  • Às vezes: um reinício do Visual Studio e meu gerenciador de arquivos de escolha (Q-Dir 4.37) resolve isso.

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

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

Quando você obtém a cópia do comando com o código [insert value], normalmente é por causa do seguinte:

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

No entanto - obviamente, às vezes 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 tem me dado alguns erros desde então (entre eles, não ser capaz de depurar). Eu reinstalei o Visual Studio e ele está funcionando melhor desde então, mas ainda assim recebo esse problema. Poderia ter a ver com alguma coisa do ReSharper estando em algum lugar?

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


Como eu estou escrevendo uma biblioteca DLL eu usei o comando xcopy para copiar a biblioteca onde o programa pode encontrar e carregá-lo. Depois de várias vezes de abrir e fechar o programa ainda havia um processo aberto dele no gerenciador de tarefas que eu não reconheci.

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


Descobri que a configuração do parâmetro Copiar para o Diretório de saída do arquivo para Copiar sempre parece ter resolvido o problema de bloqueio. Embora agora eu tenha 2 cópias dos arquivos e precise excluir um.


Enquanto /C pode 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 é a falta de cotações em torno das tags de comando predefinidas (como $TargetDir ). Quando alguém 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, causará problemas também. Adicione a opção /R 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 problema possível é que a pasta subjacente não pode ser acessada. Nesse caso, tente executar "start xcopy" vez de "xcopy" . Isso abrirá outra janela de comando, mas com privilégios de administrador.


Eu cruzei o mesmo erro, mas não é devido ao arquivo está bloqueado, mas o arquivo está faltando.

A razão pela qual o VS tentou copiar um arquivo não existente é devido ao comando de evento Post-build.

Depois que eu apaguei isso, problema resolvido.

ATUALIZAR:

Como @rhughes comentou:

A questão real é como colocar o comando aqui para funcionar, em vez de removê-lo.

e ele está absolutamente certo.


Eu enfrentei o mesmo problema no caso do XCOPY após o término da compilação. No meu caso, o problema estava acontecendo por causa das permissões READ-ONLY definidas nas pastas.

Eu adicionei o comando attrib -R antes do XCOPY e resolvi o problema.

Espero que ajude alguém!


Eu invariavelmente descobri que isso é um problema de bloqueio de arquivos. Código 4 é não é possível 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 construções falhassem.

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

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


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

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

Um simples iisreset fez o truque para mim.


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

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

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

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


Eu tive o mesmo erro com xcopy em conexão com o mecanismo de teste. Estou usando o VisualStudio Professional 2013. Por padrão Testar -> Testar Configurações -> Manter Mecanismo de Execução de Testes A 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 alguns arquivos .dlls.


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

exit 0

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

Espero que isso ajude alguém!


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


Isso pode acontecer em vários casos:

  1. Quando o caminho completo da string é maior que 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 readonly está definido no arquivo copiado ou na pasta de destino.

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

O que estava acontecendo era que esse comando estava sendo executado na pasta $ (OutDir) (no meu caso, a pasta de compilação) e não no diretório onde o arquivo csproj do projeto estava localizado (como normalmente seria esperado). Por isso, continuei recebendo erro de File not found (correspondente ao código de saída 4).

Eu não consegui descobrir isso até que escrevi cd nos eventos Post Build, para imprimir em qual diretório isso estava sendo executado.

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


Recebi este erro porque a conta de usuário na qual o TFS Build Service estava sendo executado não tinha permissões para gravar na pasta de destino. Right-click on the folder-->Properties-->Security .


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

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

Mais informações sobre o robocopy podem ser encontradas here .


Pode ser causado pelo VMWare Workstation com pastas compartilhadas

Eu tenho o problema sempre quando a pasta destinatinon do xcopy também é mapeada como pasta compartilhada em uma VM.

Eu resolvi isso com um script rodando na vm e deletando o conteúdo da pasta compartilhada.





visual-studio