Cosa non va quando Visual Studio mi dice "xcopy è terminato con codice 4"

Non ho molta familiarità con gli eventi post-build, quindi sono un po 'confuso su cosa non va con il mio programma. Durante la compilazione in Visual Studio 2010, ottengo quanto segue:

The command "xcopy C:\Users\Me\Path\Foo.bar\Library\dsoframer.ocx C:\Users\Me\Path\Foo.bar\bin\Debug\ /Y /E /D
xcopy C:\Users\Me\Path\Foo.bar\ApplicationFiles C:\Users\Me\Path\Foo.bar\bin\Debug\ /Y /E /D
xcopy C:\Users\Me\Path\url\ C:\Users\Me\Path\Foo.bar\bin\Debug\ /Y /E /D
rmdir /S /Q C:\Users\Me\Path\Foo.bar\bin\Debug\.gwt-tmp" exited with code 4.    

Il programma sembra funzionare bene, nonostante questo errore, ma non voglio ignorare questo problema e spero che non accada nulla di male. Stranamente, questa riga era iniziata come un unico comando (il primo xcopy) ma mentre continuavo a compilare il progetto (risolvendo altri problemi, principalmente riferimenti) il messaggio di errore si espanse sempre più. Qualche idea su cosa potrebbe succedere?

Modifica: ecco gli eventi post-compilazione che sembrano non riuscire -

xcopy $(ProjectDir)Library\dsoframer.ocx $(TargetDir) /Y /E /D
xcopy $(ProjectDir)ApplicationFiles $(TargetDir) /Y /E /D
xcopy $(SolutionDir)com.myUrl.gwt\www $(TargetDir) /Y /E /D
rmdir /S /Q $(TargetDir).gwt-tmp

Il codice di uscita Xcopy 4 significa " Si è verificato un errore di inizializzazione. Memoria o spazio su disco insufficienti oppure è stato immesso un nome di unità non valido o una sintassi non valida nella riga di comando " .

Sembra che Visual Studio fornisca argomenti non validi a xcopy. Controlla il comando dell'evento post-build tramite Project > Right Click > Properties > Build Events > Post Build Event.

Nota che se il file $(ProjectDir) termini macro o simili hanno spazi nei percorsi risultanti quando espansi, allora dovranno essere racchiusi tra virgolette doppie. Per esempio:

xcopy "$(ProjectDir)Library\dsoframer.ocx" "$(TargetDir)" /Y /E /D1

Passa la scheda Watch a "ouput" e cerca il comando xcopy. A volte qui trovi qualche messaggio in più (l'effettivo output di xcopy) che potrebbe aiutarti a risolvere il problema. Se non vedi la scheda output, usa il menu Visualizza-Output per mostrarla.

Oltre alla risposta accettata, l'errore può verificarsi anche quando la cartella di destinazione è di sola lettura (comune quando si utilizza TFS)

Se il file sorgente non viene trovato, xcopy restituisce anche il codice di errore 4 .

Ho ricevuto l' errore " uscito con codice 4 " quando il comando xcopy ha tentato di sovrascrivere un file di sola lettura. Sono riuscito a risolvere questo problema aggiungendo / R al comando xcopy. La / R indica che i file di sola lettura devono essere sovrascritti

vecchio comando:

XCOPY /E /Y "$(ProjectDir)source file" "destination"

nuovo comando

XCOPY /E /Y /R "$(ProjectDir)source file" "destination"

Come spiegano altre risposte, il codice di uscita 4 può avere molte cause.

Ho notato un caso in cui i nomi dei percorsi risultanti superavano la lunghezza massima consentita (proprio come qui ).

Ho sostituito xcopy con robocopy per l'evento di post build interessato; robocopy sembra gestire percorsi leggermente diversi ed è stato in grado di completare l'attività di copia che xcopy non era in grado di gestire.

Significa :

Si è verificato un errore di inizializzazione. Memoria o spazio su disco insufficienti oppure è stato immesso un nome di unità non valido o una sintassi non valida nella riga di comando.

Quindi in pratica potrebbe essere qualsiasi cosa haha ​​... prova a eseguire il comando uno alla volta dal prompt dei comandi per capire quale parte di quale comando ti sta dando problemi.

Ho capito insieme al messaggio

Specifica dell'unità non valida

quando si copia in una condivisione di rete senza specificare il nome dell'unità, ad es

xcopy . \\localhost

dove

xcopy . \\localhost\share

era atteso

Mi sono imbattuto in questo problema, quindi ho eseguito il comando xcopy dalla riga di comando e ha detto:

File creation error - The requested operation cannot be performed on a file with
 a user-mapped section open.

In realtà era Visual Studio aggrappato a qualcosa. Ho appena riavviato Visual Studio e ha funzionato.

Nel mio caso il problema era dovuto a un ordine di build errato. Un progetto aveva un comando xcopy sugli eventi post-compilazione per copiare i file dalla cartella bin a un'altra cartella. Ma a causa di dipendenze errate, venivano creati nuovi file nella cartella bin mentre xcopy era in corso.

In VS fai clic con il pulsante destro del mouse sul progetto in cui hai eventi di post-compilazione. Vai a Build Dependencies> Project Dependencies e assicurati che sia corretto. Verifica anche l'ordine di compilazione del progetto (scheda successiva alle dipendenze).

Questo errore è dovuto alla presenza di spazi vuoti in cui viene copiato il repository. Ad esempio, il mio progetto viene copiato nella posizione sottostante, c://projects/My rest project quindi puoi vedere gli spazi bianchi lì, se cambi il percorso del repository in basso, dovrebbe funzionare c://projects/myrestproject

Ho avuto lo stesso problema. Puoi anche controllare in che direzione punta la barra. Per me ha funzionato usando il backslash, invece del forward slash. Esempio

xcopy /s /y "C:\SFML\bin\*.dll" "$(OutDir)"

Invece di:

xcopy /s /y "C:/SFML/bin/*.dll" "$(OutDir)"

Avevo un comando di post build che funzionava perfettamente prima di eseguire un aggiornamento su VS 2017. Si è scoperto che gli strumenti SDK erano aggiornati e si trovavano in un nuovo percorso, quindi non riusciva a trovare lo strumento che stavo usando per firmare i miei assembly.

Questo è cambiato da questo ...

call "%VS140COMNTOOLS%vsvars32"
    "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\x64\sn.exe" -Ra "$(TargetPath)" "$(ProjectDir)Key.snk"

A questa...

"C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\x64\sn.exe" -Ra "$(TargetPath)" "$(ProjectDir)Key.snk"

Modifica molto sottile ma significativa, quindi controlla i tuoi percorsi dopo un aggiornamento se vedi questo errore.

Un'altra cosa a cui prestare attenzione è rovesciare doppio, dal momento che xcopynon li tollera nel parametro percorso di ingresso (ma non li tollera nel percorso di uscita ...).

Se qualsiasi altra soluzione è in modalità di debug, prima interromperli tutti e quindi riavviare lo studio visivo. Ha funzionato per me.

Ciò può verificarsi anche se la cartella di destinazione viene utilizzata da altri processi . Chiudi tutti i programmi che possono utilizzare la cartella di destinazione e prova.

È possibile utilizzare il monitoraggio delle risorse (strumento Windows) per controllare i processi che utilizzano la cartella di destinazione.

Questo ha funzionato per me !.