Command copy exited with code 4 when building - Visual Studio restart solves it

Viewed 175820

Every now and then when I build my solution here (with 7 projects in it) I get the dreaded 'Command copy exited with code 4' error, in Visual Studio 2010 Premium ed.

This is because of the post-build event not being able to go through.

Here's what solves the problem, temporarily

  • Sometimes: A restart of Visual Studio and I'm able to build the solution
  • Sometimes: Both a restart of Visual Studio and my file manager of choice (Q-Dir 4.37) solves it.

Here's what the post-build event looks like:

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

When you get the command copy exited with code [insert value] error, it's normally because of the following:

  • read / write permissions
  • missing files
  • wrong directories

However - obviously at times when I build the solution, there's no problem.

FYI, I uninstalled ReSharper 5.1.1 two weeks ago and Visual Studio's been giving me some errors since then (among them not being able to debug). I re-installed Visual Studio and it's working better since then, but still get this problem. Could it have to do with some ReSharper stuff being somewhere?

Have you had the same problem and solved it? Or do you have any possible solution to it?

28 Answers

If you are running Windows 7 onward, you can try the new 'robocopy' command:

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

More information about robocopy can be found here.

In my case my $(OutDir) was simply ..\..\Build\ i.e. some relative path. And, when I was trying to xcopy as follows xcopy /y "$(OutDir)Proj1.dll" "Anypath\anyfolder\" I was getting the exit code error 4.

What's happening was, this command was getting executed in the $(OutDir) (in my case build folder) itself and not the directory where the csproj file of the project was located (as we would normally expect). Hence, I kept getting File not found error (corresponding to exit code 4).

I couldn't figure this out until I wrote cd in the Post Build events, to print which directory this was getting executed in.

So, to summarize, if we're wishing to copy / xcopy files from the $(OutDir), either use "$(TargetDir)" (which is complete path for output directory) or need not specify any path at all.

To expand on rhughes answer,

The robocopy works beautifully, just incase you need to include sub directories you can use /e to include subs and copy empty directories or /s to include subs excluding empty directories.

Also robocopy will report back a few things like if new files were copied, this will cause VS to complain since anything above 0 is a failure and robocopy will return 1 if new files have been found. Its worth to mention that robocopy first compares the Source/Dest and only copies the updated/new files.

To get around this use:

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

If you are here because your project fails to build on a build server, but builds fine "manually" on a dev machine, and you are doing xcopy only for debugging and to emulate a production environment on a dev machine, then you may want to look at this solution:

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

You simply turn off post build events on the build server using

msbuild foo.sln /p:PostBuildEvent=

This is not good enough if you have other post build events that also need to run on the build server, and it is not a general solution. However, since there are so many different causes of this problem, there cannot be a general solution. One of the many answers to this question (and its duplicates) will probably help, but be careful with approaches that only somehow circumvent error handling (such as xcopy /C). Those may work for you, particularly also in the build server scenario, but I think this one is more reliable, IF it can be used.

It has also been suggested that with newer versions of Visual Studio, the problem no longer exists, so if you are using an old version, consider updating your build tools.

Error code 4 can mean a lot of things, so I recommend reading the other answers as well until you find a solution that works for you AND you understand WHY it works (some solutions only disable error handling, which may only mask the problem but not solve it).

This can be a file locking issue related to parallel building. A workaround is to not use parallel building. This is the default behavior, but if you are using the -m option, then projects will be built in parallel. The following variations should not build projects in parallel, so you will not run into the file locking problem.

msbuild -m:1
msbuild -maxcpucount:1
msbuild

Note that, contrary to what has been said here, this even happens with the "latest" version of MSBuild (from Build Tools for Visual Studio 2019).

The best solution is probably to make sure you don't need to copy files in a post-build step. In some situations, you can also disable post-build steps when building with MSBuild on a build server: https://stackoverflow.com/a/55899347/2279059

I want to amplify and crystallize these two answers: @Vemul's, @Srihari Chinna's.

  • Make sure that your source path exists and that the process has access to it.
    • This is especially true if you're using variable substitution to assemble the source path.
Related