> 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