Daniel Hommel writes: > Ross Patterson writes: >> I wouldn't go so far as to say it's by design, but it certainly is the >> way CCNet works. The build has already started and must have a final >> status, and builds either succeed or fail - there is no in-between >> state. I'll grant that the abort code should include an error to the >> effect that the build failed because it was aborted, rather than just >> being quiet. >> >> Ross > > > While investigating on this i found out that it seems to be the easiest > way to fix the mentioned behavior to pull the RunnableProcess class out > of the ProcessExecutor class and also use it in the ProcessMonitor > instead of using the Process class directly. If that's not a problem i > think i can provide a patch. > > regards, > > Daniel
I tried to insert an error message in the standard error output of the executable which is passed to the ProcessResult class. It is working for the executable task and the nant task since they don't use a logger like the msbuild task does and both use the same XML format (seems like msbuild is the only task that doesn't). With the msbuild task i see two options. The first option would be to merge the output of the logger AND the ProcessResult transformed into XML. A drawback is that you see each error or warning 2 times in the build report page (could be fixed). The second option would be to somehow insert the error message in the XML file that the logger writes before merging it. A different and maybe the best approach would be to not insert the error message in the ProcessResult and just throw an exception with a meaningful message like the one that gets thrown when a timeout occurs. Which way to go? I guess i'd prefer throwing an exception. regards, Daniel
