This project is read-only.

Microsoft RoboCopy Task - again

Oct 19, 2010 at 7:15 PM

There was a post a while back that demonstrated the use of "SuccessErrorCodes" and "FailureErrorCodes" for the robocopy wrapper - which seem to not be implemented in the current extension pack.

Robcopy returns several error codes that are non zero and not failures... how are these handled? 

The extension pack help does not have any examples of this.... 

Oct 19, 2010 at 7:21 PM

are you thinking of the GenericTool task? There is a dedicated RoboCopy task which handles the return codes internally and returns 0 for success codes



Oct 19, 2010 at 7:30 PM

I am testing with the RoboCopy task... which is returning 3... which in my case is not an error... if I ignore the exit code then I open up the possibility of ignoring what I would consider an error... so question is... HOW is an error defined in this case?  A Non zero test for robocopy doesn't really cut it

Oct 19, 2010 at 8:04 PM

ah, are you using the August Release? I fixed a bug on this yesterday -

Can you compile the latest code ( or and see if it works.


Oct 19, 2010 at 9:33 PM

Ok... think I have it built.... any docs on how to install it?

Oct 19, 2010 at 9:56 PM

Yes, but they could do with improving. I just updated and posted here:

Let me know how you get along and I'll update if you get into difficulty.


Oct 19, 2010 at 10:13 PM

Ok... that fixed it... (had to dump into the 4.0 directory) couple questions.

What happened to the original implementation where you could define which return codes would pass and which would fail?

When will this make it into a download-able binary?


Oct 19, 2010 at 10:18 PM


I'm pretty sure it never supported that. That's the generictool task.

The fix will be in the next release, eta Nov / Dec


Oct 20, 2010 at 12:29 AM

I went with generic tool because waiting was not an option and I like defining what error codes to stop on.

Oct 20, 2010 at 9:44 AM

Hey Scott

WRT waiting I can't really help you there, but I don't see anything wrong with building the latest code and using it (assuming you are not hampered by a red tape brigade).

WRT defining error codes to stop on, I think you raise a good point. I've updated the task to expose a ReturnCode property. The execution logic is all the same, i.e. the ExitCode is masked to zero for any non-zero success codes. CS details here:

Thanks for the feedback on this issue.