La copia del comando salió con el código 4 al compilar: el reinicio de Visual Studio lo resuelve

De vez en cuando, cuando construyo mi solución aquí (con 7 proyectos), aparece el temido error 'Copia de comando salido con código 4', en Visual Studio 2010 Premium ed.

Esto se debe a que el evento posterior a la compilación no puede pasar.

Esto es lo que resuelve el problema, temporalmente

• A veces: reinicio de Visual Studio y puedo crear la solución
• A veces: tanto el reinicio de Visual Studio como el administrador de archivos de mi elección (Q-Dir 4.37) lo resuelven.

Así es como se ve el evento posterior a la compilación:

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

Cuando sale el comando copiar salido con error de código [insertar valor], normalmente se debe a lo siguiente:

• permisos de lectura / escritura
• archivos perdidos
• directorios equivocados

Sin embargo, obviamente, cuando construyo la solución, no hay problema.

Para su información, desinstalé ReSharper 5.1.1 hace dos semanas y Visual Studio me ha estado dando algunos errores desde entonces (entre ellos no poder depurar). Reinstalé Visual Studio y funciona mejor desde entonces, pero sigo teniendo este problema. ¿Podría tener que ver con algunas cosas de ReSharper en algún lugar?

¿Has tenido el mismo problema y lo has resuelto? ¿O tienes alguna solución posible?

Siempre he encontrado que se trata de un problema de bloqueo de archivos. El código 4 es No se puede acceder al archivo. Una solución parcial que encontré es usar la opción / C para xcopy (que continúa en caso de error). Realmente no es una solución, pero principalmente ha impedido que mis compilaciones fallen.

Otra solución que solo funciona en 32 bits es usar la herramienta de desbloqueo para liberar los identificadores de Windows en el archivo antes de la copia.

Editar: Me acabo de dar cuenta de que también funciona con menos de 64 bits.

Si bien /Cpuede ignorar los errores, puede que no sea la solución real, ya que podría haber archivos que DEBEN copiarse para que la compilación sea exitosa.

El problema más común son las comillas faltantes alrededor de las etiquetas de comando predefinidas (como $TargetDir). Cuando uno crea varias ramas y rutas en código o TFS, hay muchas posibilidades de que esto ocurra.

A veces, si el archivo es de solo lectura, también causará problemas. Agregue la /Ropción para permitir la copia de archivos de solo lectura. Puede encontrar la lista de opciones disponibles en:

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

Otro posible problema es que no se puede acceder a la carpeta subyacente. Si es así, intente actuar en "start xcopy"lugar de "xcopy". Esto abrirá otra ventana de comando pero con privilegios de administrador.

Crucé el mismo error, pero no se debe a que el archivo está bloqueado, pero falta el archivo.

La razón por la cual VS intentó copiar un archivo no existente, es por el comando de evento Post-build.

Después de aclarar eso, el problema se resolvió.

ACTUALIZAR:

Como comentó @rhughes:

El verdadero problema es cómo hacer que el comando funcione aquí, en lugar de eliminarlo.

Y tiene toda la razón.

También me he enfrentado a este problema. Vuelva a verificar el resultado en la ventana de error.

En mi caso, una cola \se estrellaba xcopy (como estaba usando $(TargetDir)). En mi caso $(SolutionDir)..\bin. Si está utilizando cualquier otra salida, esto debe ajustarse.

También tenga en cuenta que start xcopyno lo soluciona, si el error desaparece después de la compilación. ¡Podría haber sido suprimido por la línea de comando y no se ha copiado ningún archivo!

Por cierto, puede ejecutar manualmente sus comandos xcopy en un shell de comandos. Obtendrá más detalles cuando los ejecute allí, señalando en la dirección correcta.

En caso de que el evento posterior a la compilación contenga el comando copy / xcopy para copiar el resultado de la compilación en algún directorio (que generalmente es la operación posterior a la compilación más común), el problema puede ocurrir en caso de que la ruta completa del directorio de los destinos de origen o destino contenga nombres de carpetas que incluyen espacios Elimine el espacio para los nombres de directorio e intente.

Como se menciona en muchos sitios, hay varias razones para esto. Para mí se debió a la longitud del origen y el destino (longitud de la ruta). Intenté xcopy en el símbolo del sistema y no pude escribir la fuente y la ruta completas (después de algunos caracteres no le permitirá escribir). Luego reduje la longitud del camino y pude correr. Espero que esto ayude.

Ejecute VS en modo Administrador y debería funcionar bien.

Recibí este error porque la cuenta de usuario con la que se ejecutaba TFS Build Service no tenía permisos para escribir en la carpeta de destino. Right-click on the folder-->Properties-->Security.

Esto puede suceder en múltiples casos:

1. Cuando la ruta de la cadena completa es más larga que 254 caracteres.
2. Cuando el nombre del archivo a copiar es incorrecto.
3. Cuando la ruta de destino es incorrecta.
4. Cuando el atributo de solo lectura se establece en el archivo copiado o en la carpeta de destino.

Recibí este error porque el archivo se abrió en otra instancia.

Cuando cerré el archivo y volví a construir la solución, se copió con éxito.

Enfrenté el mismo problema en el caso de XCOPY después de que se realizó la construcción. En mi caso, el problema estaba ocurriendo debido a los permisos de SOLO LECTURA establecidos en las carpetas.

Agregué el comando attrib -R antes de XCOPY y resolvió el problema.

Espero que ayude a alguien!

Tuve el mismo error con xcopy en relación con el motor de prueba. Estoy usando VisualStudio Professional 2013. De manera predeterminada, Prueba -> Configuración de prueba -> Mantener el motor de ejecución de prueba en ejecución parece ser la razón de mi código de error 4 con xcopy. Apagarlo resolvió el problema. El motor de ejecución parece mantenerse en algunos .dlls.

Yo tuve el mismo problema. Una simple 'Solución limpia' en VS borró el error, pero fue una solución temporal.

Descubrí que configurar el parámetro Copiar al directorio de salida del archivo en Copiar siempre parece haber solucionado el problema de bloqueo. Aunque ahora tengo 2 copias de los archivos y necesito eliminar uno.

Yo tuve el mismo problema. Sin embargo, nada funcionó para mí. Resolví el problema agregando

exit 0

a mi código El problema era que mientras hacía la copia de los archivos, a veces no se podía encontrar el último archivo y el murciélago devolvía un valor distinto de cero.

¡Espero que esto ayude a alguien!

Si está ejecutando Windows 7 en adelante, puede probar el nuevo comando 'robocopy':

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

Puede encontrar más información sobre robocopy aquí .

Me enfrenté al mismo problema. Eliminé los eventos posteriores a la compilación y comenzó a funcionar. Algunas veces, cuando agregamos algunos componentes SQL, también puede agregar comandos posteriores a la compilación.

Estoy obteniendo algo similar usando una xcopy con la opción / exclude. En mi caso, descubrí que editar el evento posterior a la compilación (algo inofensivo como una nueva línea después del comando) y guardar el proyecto hace que ocurra el error. Volver a guardar el archivo especificado en la opción / excluir hace que vuelva a funcionar.

Mientras escribo una biblioteca DLL, utilicé el comando xcopy para copiar la biblioteca donde el programa puede encontrarla y cargarla. Después de varias veces abrir y cerrar el programa, todavía había un proceso abierto en el administrador de tareas que no reconocí.

Busque cualquier proceso desde el cual se pueda usar el archivo y ciérrelo.

Lo que me arregló : busque la solución específica para el proyecto que desea, es decir, NO el archivo de solución general para todos los proyectos.

Intente: probé todo lo demás mencionado aquí, pero fue en vano.

No veo nada aquí que sugiera que se trata de una aplicación web, pero yo mismo he experimentado este problema: tengo dos comandos xcopy en un evento posterior a la compilación y solo uno de ellos estaba fallando. Algo tenía un bloqueo en el archivo, y no era Visual Studio (ya que intenté reiniciarlo).

La única otra cosa que habría usado el dll que construí fue IIS. Y he aquí,

Un simple iisresethizo el truco para mí.

Tuve el mismo problema. Fue causado por tener la misma bandera dos veces, por ejemplo:

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

Observe que la bandera "/ e" aparece dos veces. Eliminar el duplicado resolvió el problema.

En mi caso, mi $(OutDir)era simplemente ..\..\Build\un camino relativo. Y, cuando estaba tratando de copiar de la siguiente manera xcopy /y "$(OutDir)Proj1.dll" "Anypath\anyfolder\", recibía el error de código de salida 4.

Lo que sucedió fue que este comando se estaba ejecutando en el $ (OutDir) (en mi caso, la carpeta de compilación) y no en el directorio donde se encontraba el archivo csproj del proyecto (como normalmente esperaríamos). Por lo tanto, seguí recibiendoFile not found error (correspondiente al código de salida 4).

No pude resolver esto hasta que escribí cden los eventos Post Build, para imprimir en qué directorio se estaba ejecutando esto.

Entonces, para resumir, si deseamos copy/ xcopyarchivos del $(OutDir), use "$(TargetDir)"(que es la ruta completa para el directorio de salida) o no necesita especificar ninguna ruta en absoluto.

Puede ser causado por VMWare Workstation con carpetas compartidas

Siempre tengo el problema cuando la carpeta de destino del xcopy también está asignada como Carpeta compartida en una máquina virtual.

Lo resolví con un script que se ejecutaba en el vm y borraba el contenido de la carpeta compartida.

Para ampliar la respuesta de Rhughes,

La robocopy funciona de maravilla, solo en caso de que necesite incluir subdirectorios que puede usar /epara incluir subs y copiar directorios vacíos o /spara incluir subs excluyendo directorios vacíos.

Además, robocopy informará algunas cosas, como si se copiaron nuevos archivos, esto hará que VS se queje ya que cualquier cosa por encima de 0 es un error y robocopy devolverá 1 si se han encontrado nuevos archivos. Vale la pena mencionar que robocopy primero compara el origen / destino y solo copia los archivos actualizados / nuevos.

Para evitar este uso:

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

Si está aquí porque su proyecto no se puede compilar en un servidor de compilación, pero se compila bien "manualmente" en una máquina de desarrollo, y está haciendo xcopysolo para depurar y emular un entorno de producción en una máquina de desarrollo, entonces es posible que desee buscar en esta solución:

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

Simplemente desactive los eventos posteriores a la compilación en el servidor de compilación utilizando

msbuild foo.sln /p:PostBuildEvent=

Esto no es lo suficientemente bueno si tiene otros eventos posteriores a la compilación que también deben ejecutarse en el servidor de compilación, y no es una solución general. Sin embargo, dado que hay tantas causas diferentes de este problema, no puede haber una solución general. Una de las muchas respuestas a esta pregunta (y sus duplicados) probablemente ayudará, pero tenga cuidado con los enfoques que solo de alguna manera eluden el manejo de errores (como por ejemplo xcopy /C). Esos pueden funcionar para usted, particularmente también en el escenario del servidor de compilación, pero creo que este es más confiable, SI se puede usar.

También se ha sugerido que con las versiones más nuevas de Visual Studio, el problema ya no existe, por lo que si está utilizando una versión anterior, considere actualizar sus herramientas de compilación.

El código de error 4 puede significar muchas cosas, por lo que recomiendo leer las otras respuestas también hasta que encuentre una solución que funcione para usted Y entienda POR QUÉ funciona (algunas soluciones solo deshabilitan el manejo de errores, lo que puede enmascarar el problema pero no resuélvelo).

Esto puede ser un problema de bloqueo de archivos relacionado con la construcción paralela. Una solución alternativa es no usar la construcción paralela. Este es el comportamiento predeterminado, pero si está utilizando la -mopción, los proyectos se construirán en paralelo. Las siguientes variaciones no deberían construir proyectos en paralelo, por lo que no se encontrará con el problema de bloqueo de archivos.

msbuild -m:1
msbuild -maxcpucount:1
msbuild

Tenga en cuenta que, al contrario de lo que se ha dicho aquí, esto incluso sucede con la versión "más reciente" de MSBuild (de Build Tools para Visual Studio 2019).

Probablemente, la mejor solución es asegurarse de que no necesita copiar archivos en un paso posterior a la compilación. En algunas situaciones, también puede deshabilitar los pasos posteriores a la compilación al compilar con MSBuild en un servidor de compilación: https://stackoverflow.com/a/55899347/2279059