Mark Modrall wrote:
Hi...
The <xslt> question of this morning comes out of frustration
trying to call nunit from ant. Ant is being called from CruiseControl,
and I'm trying to get the nunit output in a form that CC will recognize
and process for its status. I have to admit it's almost got me tearing
my hair out. None of the wires seem to quite connect.
Nunit-console (which <nunit> wraps) has a number of
properties which produce broken xml. /xmlConsole spits xml out to the
console, but after it spits out some version junk (making the result
unparsable). /transform a) ignores the output encoding in the
stylesheet you give it and b) spits out a line of the regular output *in
front of* the xml, making *it* unparseable.
The <nunit> .dotnet plugin supports failOnerror="true" but
not resultproperty="foo". If you set failOnerror and nunit fails, it
just stops, meaning the <xslt> doesn't get done. You can't get <nunit>
to *tell* you it failed without failonerror.
well, file a bug report against the latest antlib beta :)
I'm down to using <exec> to run nunit-console, putting
/xml=temp.out on that to get the raw output to a file, applying my
<xslt> to produce *another* output file, and then testing the
resultproperty to see if I should fail the build. Not very elegant.
nasty.
How about writing a new Nunit task runner in C# that generates proper XML?
Its the best long term solution.
I already had to dump <nant> (because it wouldn't use VS
2005 projects) and <msbuild> because it has *neither* failonerror *nor*
resultproperty.
file bugreps, they probably assume the builds work. you can also use
ant-contrib's try/catch stuff.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
