Thanks for the answers, but I ended up doing two things:

• Recompiled the text replacement app (fart) without the spinner. Even after doing this CC was still failing for some reason, so I...
• Moved batch executables to the msbuild file instead of cc config file. CC then built successfully.

I m sure if I understood CC better I could have gone about this better way but for now this does the trick!

I also ran into this issue with fart and a ci system. Rather than recompile the executable, I redirected the output to NUL.

First I determined that the spinner output was on stderr. Then I appended "2>NUL" to the command line which called fart, and it no longer farted a spinner on stderr.

Anybody else getting a pinwheel in a smelly breeze visual from that last sentence?

In my case I needed to run fart.exe from a batch file which was run later on by Jenkins, and here is what I found out.

fart.exe returns in %errorlevel% the amount of replacements that are done. If that amount is 1, that will be the value of %errorlevel%, which means having an exit code 1, what will make Jenkins fail.

In order to fix this here is what I added to my batch file:

REM standard "fart.exe" error-handling block; 9009 (missing program) is bad, anything else above 0 is OK and should be reset to 0 for standard handling
if ERRORLEVEL 9009 (
    REM do nothing
) else (
    if ERRORLEVEL 1 CMD /C EXIT 0
)

REM ensure that we exit with the current errorlevel context...
exit %errorlevel%

Adding ECHO OFF to the call of fart.exe made the %errorlevel% value be 0 again, but by doing that the replacements done by fart stopped being successful.

I hope this helps someone!

I have run into the same issue. And, found out FART returns errorlevel =1 when it success and return errorlevel = 0 when it failed with "access denied" or "file not found" and etc. So, force errorlevel to 0 when it runs successfully and force it to 1 when it fails. It works for me.

The successExitCodes list is supposed to be a list of ints. Here s a couple of suggestions:

1. Create a small batch file that runs the executable and call your batch file (instead of fart) using the executable task.
2. Try removing the non ints from the successExitCodes and verify what exit code fart is returning... sometimes you get unexpected return codes, like when using robocopy.

For command line apps, you can redirect output to a file using the > character. A call to your app would look like:

fart.exe myfile.txt string1 string2 > myoutput.txt

Adding the redirect to your buildArgs property should do the trick.

This line seems to work using fart:

<exec program="fart.exe" commandline="${filename} 1.0 1.1" verbose="true" failonerror="false" />

However I am not sure if the failonerror can be handled otherwise