Copia del comando terminata con il codice 4 durante la creazione: il riavvio di Visual Studio lo risolve

Di tanto in tanto quando creo la mia soluzione qui (con 7 progetti in essa) ottengo il temuto errore "Copia comando uscito con codice 4", in Visual Studio 2010 Premium ed.

Ciò è dovuto al fatto che l'evento post-build non è stato in grado di passare.

Ecco cosa risolve il problema, temporaneamente

• A volte: un riavvio di Visual Studio e sono in grado di creare la soluzione
• A volte: sia un riavvio di Visual Studio che il mio file manager di scelta (Q-Dir 4.37) lo risolvono.

Ecco come si presenta l'evento post-build:

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

Quando si ottiene la copia del comando chiusa con errore di codice [inserire valore], è normalmente a causa di quanto segue:

• permessi di lettura / scrittura
• file mancanti
• directory sbagliate

Tuttavia, ovviamente quando creo la soluzione, non c'è nessun problema.

Cordiali saluti, ho disinstallato ReSharper 5.1.1 due settimane fa e Visual Studio mi ha dato alcuni errori da allora (tra i quali non è stato possibile eseguire il debug). Ho reinstallato Visual Studio e da allora funziona meglio, ma ho ancora questo problema. Potrebbe avere a che fare con alcune cose di ReSharper che si trovano da qualche parte?

Hai avuto lo stesso problema e risolto? O hai qualche soluzione possibile?

Ho sempre trovato questo un problema di blocco dei file. Il codice 4 è Impossibile accedere al file. Una soluzione parziale che ho trovato è quella di utilizzare l'opzione / C per xcopy (che continua in caso di errore). Non è davvero una soluzione, ma soprattutto ha impedito il fallimento delle mie build.

Un'altra soluzione che funziona solo su 32 bit è di utilizzare il software di sblocco strumento per liberare le maniglie delle finestre sul file prima della copia.

Modifica: ho appena realizzato che funziona anche con 64 bit.

Anche se /Cpuò ignorare gli errori, potrebbe non essere la vera soluzione in quanto potrebbero esserci dei file che DEVONO essere copiati affinché la compilazione abbia esito positivo.

Il problema più comune sono le virgolette mancanti attorno ai tag di comando predefiniti (come $TargetDir). Quando si creano vari rami e percorsi in codice o TFS, c'è un'alta probabilità che ciò avvenga.

A volte se il file è di sola lettura, causerà anche problemi. Aggiungi l' /Ropzione per consentire la copia dei file di sola lettura. Puoi trovare un elenco delle opzioni disponibili su:

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

Un altro possibile problema è che non è possibile accedere alla cartella sottostante. In tal caso, prova a esibirti "start xcopy"invece di "xcopy". Questo aprirà un'altra finestra di comando ma con privilegi di amministratore.

Ho attraversato lo stesso errore, ma non è dovuto al fatto che il file è bloccato, ma il file è mancante.

Il motivo per cui VS ha provato a copiare un file inesistente, è a causa del comando di evento Post-build.

Dopo averlo chiarito, il problema è stato risolto.

AGGIORNARE:

Come ha commentato @rhughes:

Il vero problema è come far funzionare il comando qui, piuttosto che rimuoverlo.

e ha assolutamente ragione.

Ho riscontrato anche questo problema. Controlla il risultato nella finestra di errore.

Nel mio caso, una coda \stava andando in crash xcopy (mentre stavo usando $(TargetDir)). Nel mio caso $(SolutionDir)..\bin. Se si utilizza qualsiasi altro output, è necessario modificarlo.

Si noti inoltre che start xcopynon lo risolve, se l'errore scompare dopo la compilazione. Potrebbe essere stato appena eliminato dalla riga di comando e nessun file è stato effettivamente copiato!

È possibile eseguire manualmente i comandi xcopy in una shell dei comandi. Otterrai maggiori dettagli quando li eseguirai lì, indicandoti nella giusta direzione.

Nel caso in cui l'evento post build contenga il comando copy / xcopy per la copia dell'output build in alcune directory (che di solito è l'operazione post build più comune), il problema può verificarsi nel caso in cui il percorso completo della directory delle destinazioni di origine o destinazione contenga nomi di cartelle che includono spazi. Rimuovere lo spazio per i nomi di directory e provare.

Come menzionato in molti siti, ci sono varie ragioni per questo. Per me era dovuto alla lunghezza di Origine e Destinazione (Lunghezza del percorso). Ho provato xcopy nel prompt dei comandi e non sono stato in grado di digitare l'origine e il percorso completi (dopo alcuni caratteri non è possibile digitare). Ho quindi ridotto la lunghezza del percorso e sono riuscito a correre. Spero che questo ti aiuti.

Esegui VS in modalità amministratore e dovrebbe funzionare correttamente.

Ho ricevuto questo errore perché l'account utente in cui era in esecuzione TFS Build Service non aveva le autorizzazioni per scrivere nella cartella di destinazione. Right-click on the folder-->Properties-->Security.

Questo può accadere in più casi:

1. Quando il percorso completo della stringa è più lungo di 254 caratteri.
2. Quando il nome del file da copiare è errato.
3. Quando il percorso target è sbagliato.
4. Quando l'attributo readonly è impostato sul file copiato o sulla cartella di destinazione.

Ho ricevuto questo errore a causa del file è stato aperto in un'altra istanza.

quando ho chiuso il file e ricostruito nuovamente la soluzione, è stato copiato correttamente.

Ho riscontrato lo stesso problema in caso di XCOPY al termine della compilazione. Nel mio caso il problema si stava verificando a causa delle autorizzazioni SOLO LETTURA impostate sulle cartelle.

Ho aggiunto il comando attrib -R prima di XCOPY e ho risolto il problema.

Spero che aiuti qualcuno!

Ho avuto lo stesso errore con xcopy in relazione al Test Engine. Sto usando VisualStudio Professional 2013. Per impostazione predefinita Test -> Impostazioni test -> Mantieni il motore di esecuzione del test in esecuzione sembra essere il motivo del mio codice di errore 4 con xcopy. La disattivazione ha risolto il problema. Il motore di esecuzione sembra mantenere alcuni file DLL.

Ho avuto lo stesso problema. Una semplice "soluzione pulita" in VS ha eliminato l'errore, ma era una soluzione temporanea.

Ho scoperto che l'impostazione del parametro Copia nella directory di output su Copia sempre sembra aver risolto il problema di blocco. Anche se ora ho 2 copie dei file e devo eliminarne uno.

Ho avuto lo stesso problema. Tuttavia, nulla ha funzionato per me. Ho risolto il problema aggiungendo

exit 0

al mio codice. Il problema era che mentre stavo facendo la copia dei file, a volte l'ultimo file non veniva trovato e la mazza restituiva un valore diverso da zero.

Spero che questo aiuti qualcuno!

Se stai eseguendo Windows 7 in poi, puoi provare il nuovo comando 'robocopy':

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

Ulteriori informazioni su robocopy sono disponibili qui .

Ho affrontato lo stesso problema. Ho eliminato gli eventi post-build e ha iniziato a funzionare. Alcune volte quando si aggiungono alcuni componenti SQL, è possibile che vengano aggiunti anche comandi post build.

Ricevo qualcosa di simile usando un xcopy con l'opzione / exclude. Nel mio caso, ho scoperto che la modifica dell'evento post-build (qualcosa di innocuo come una nuova riga dopo il comando) e il salvataggio del progetto provoca l'errore. Il salvataggio del file specificato nell'opzione / exclude fa sì che funzioni di nuovo.

Mentre scrivo una libreria DLL ho usato il comando xcopy per copiare la libreria dove il programma può trovarla e caricarla. Dopo diverse volte di apertura e chiusura del programma c'era ancora un processo aperto nel taskmanager che non riconoscevo.

Cercare qualsiasi processo da cui è possibile utilizzare il file e chiuderlo.

Che cosa l'ha risolto per me : approfondisci la soluzione specifica per il progetto che desideri, ovvero NON il file della soluzione globale per tutti i progetti.

Provate - ho provato tutto il resto menzionato qui ma senza risultati.

Non vedo nulla qui per suggerire che si tratta di un'app Web, ma ho riscontrato questo problema da solo: ho due comandi xcopy in un evento post-build e solo uno di questi non ha funzionato. Qualcosa aveva un blocco sul file e non era Visual Studio (come ho provato a riavviarlo).

L'unica altra cosa che avrebbe usato la DLL che ho creato era IIS. Ed ecco,

Un semplice ha iisresetfatto il trucco per me.

Ho avuto lo stesso problema. È stato causato dal fatto di avere lo stesso flag due volte, ad esempio:

if $ (ConfigurationName) == Release (xcopy "$ (TargetDir) . " "$ (SolutionDir) Deployment \ $ (ProjectName) \" / e / d / i / y / e)

Si noti che il flag "/ e" appare due volte. La rimozione del duplicato ha risolto il problema.

Nel mio caso il mio $(OutDir)era semplicemente ..\..\Build\un percorso relativo. E, quando stavo tentando di eseguire una copia di xcopy come segue, xcopy /y "$(OutDir)Proj1.dll" "Anypath\anyfolder\"ho visualizzato l'errore 4 del codice di uscita.

Quello che stava succedendo era che questo comando veniva eseguito nel $ (OutDir) (nel mio caso cartella di build) stesso e non nella directory in cui si trovava il file csproj del progetto (come normalmente ci aspetteremmo). Quindi, ho continuato a ricevere File not founderrori (corrispondente al codice di uscita 4).

Non sono riuscito a capirlo fino a quando non ho scritto cdnegli eventi Post Build, per stampare in quale directory questo veniva eseguito.

Quindi, per riassumere, se desideriamo copy/ xcopyfile da $(OutDir), utilizzare "$(TargetDir)"(che è il percorso completo per la directory di output) o non è necessario specificare alcun percorso.

Può essere causato da VMWare Workstation con cartelle condivise

Ho il problema sempre quando la cartella destinatinon del xcopy è anche mappata come cartella condivisa in una macchina virtuale.

L'ho risolto con uno script in esecuzione nel vm ed eliminando il contenuto della cartella condivisa.

Per espandere la risposta di rhughes,

Il robocopy funziona magnificamente, solo nel caso in cui sia necessario includere sottodirectory che è possibile utilizzare /eper includere sottotitoli e copiare directory vuote o /sper includere sottotitoli esclusi quelli vuoti.

Inoltre, robocopy riporterà alcune cose come se fossero stati copiati nuovi file, questo farà lamentare VS poiché qualsiasi cosa sopra 0 è un errore e robocopy restituirà 1 se sono stati trovati nuovi file. Vale la pena ricordare che robocopy confronta prima Source / Dest e copia solo i file aggiornati / nuovi.

Per aggirare questo uso:

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

Se sei qui perché il tuo progetto non riesce a compilare su un server di compilazione, ma costruisce bene "manualmente" su una macchina di sviluppo e stai facendo xcopysolo per il debug e per emulare un ambiente di produzione su una macchina di sviluppo, allora potresti voler guardare a questa soluzione:

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

È sufficiente disattivare gli eventi post build sul server build utilizzando

msbuild foo.sln /p:PostBuildEvent=

Questo non è abbastanza buono se hai altri eventi post build che devono anche essere eseguiti sul server build e non è una soluzione generale. Tuttavia, poiché ci sono così tante cause diverse di questo problema, non può esserci una soluzione generale. Una delle molte risposte a questa domanda (e ai suoi duplicati) probabilmente aiuterà, ma fai attenzione con approcci che in qualche modo aggirano la gestione degli errori (come xcopy /C). Questi potrebbero funzionare per te, in particolare anche nello scenario di build server, ma penso che questo sia più affidabile, SE può essere utilizzato.

È stato anche suggerito che con le versioni più recenti di Visual Studio, il problema non esiste più, quindi se si utilizza una versione precedente, prendere in considerazione l'aggiornamento degli strumenti di compilazione.

Il codice di errore 4 può significare molte cose, quindi ti consiglio di leggere anche le altre risposte finché non trovi una soluzione che funzioni per te E capisci PERCHÉ funziona (alcune soluzioni disabilitano solo la gestione degli errori, che può solo mascherare il problema ma non risolvilo).

Questo può essere un problema di blocco dei file relativo alla costruzione parallela. Una soluzione alternativa è di non utilizzare la costruzione parallela. Questo è il comportamento predefinito, ma se si utilizza l' -mopzione, i progetti verranno creati in parallelo. Le seguenti varianti non dovrebbero creare progetti in parallelo, quindi non si verificherà il problema del blocco dei file.

msbuild -m:1
msbuild -maxcpucount:1
msbuild

Si noti che, contrariamente a quanto è stato detto qui, ciò accade anche con la versione "più recente" di MSBuild (da Build Tools for Visual Studio 2019).

La soluzione migliore è probabilmente quella di assicurarsi che non sia necessario copiare i file in un passaggio post-build. In alcune situazioni, puoi anche disabilitare i passaggi post-build durante la compilazione con MSBuild su un server di build: https://stackoverflow.com/a/55899347/2279059