views:

353

answers:

4

I inherited an existing project with a failing build. I can see the exception in the ccnet.log file:

Exception: System.Xml.XmlException: Name cannot begin with the '%' character, hexadecimal value 0x25. Line 17, position 100.
   at System.Xml.XmlTextReaderImpl.Throw(Exception e)
   at System.Xml.XmlTextReaderImpl.Throw(String res, String[] args)
   at System.Xml.XmlTextReaderImpl.Throw(Int32 pos, String res, String[] args)
   at System.Xml.XmlTextReaderImpl.ParseQName(Boolean isQName, Int32 startOffset, Int32& colonPos)
   at System.Xml.XmlTextReaderImpl.ParseElement()
   at System.Xml.XmlTextReaderImpl.ParseDocumentContent()
   at System.Xml.XmlTextReaderImpl.Read()
   at System.Xml.XmlWriter.WriteNode(XmlReader reader, Boolean defattr)
   at ThoughtWorks.CruiseControl.Core.Util.XmlFragmentWriter.WriteNode(XmlReader reader, Boolean defattr)
   at ThoughtWorks.CruiseControl.Core.Util.XmlFragmentWriter.WriteNode(String xml)

Any idea which xml file this is and how can I fix it? The annoying thing is that the build turns red, but it is not being added to the recent builds web page.

EDIT Let me clarify: this happens at the end of the build, probably when it tries to generate the build report xml or something (I disabled all merge publishers)

A: 

Most likely ccnet.config in the CC.NET installation directory.

HTH, Kent

Kent Boogaart
try to locate Line 17, position 100 in ccnet.config
codemeit
I don't really think its ccnet.config, because this error happens at the end of the build (sorry, I will add it to the question)
Grzenio
+1  A: 

I'm not sure that this is your ccnet.config file, due to the stack frame:

System.Xml.XmlWriter.WriteNode

...I don't believe that CC.NET writes back to its own ccnet.config file. This is probably happening during a build, no?

It's hard to say exactly what file it's using from your stack trace. Were there more stack frames from higher up?

Whatever XML file it is, the problem's at line 17, row 100.

You might find that this problem is due to a statistics file, if you're using statistics. Like I said, it's hard to say without a fuller stack trace.

Sometimes a statistics file can become corrupt if the disk is completely filled. You might have to go in and manually correct the tail of the XML file, making sure all elements are closed properly.

EDIT

It occurred to me that this issue is probably related to the merging of files by the publisher step. In your ccnet.config file, there's a step that occurs at the end of the build in which CC merges together several files, usually XML files, and creates one larger XML document from which the web dashboard is generated. My guess is that one of the files you're merging contains this spurious character, and the merge step is failing.

In my config file, the step in question looks something like this:

<publishers>
  <merge>
    <files>
      <file>E:\Blah\Cruise Reports\*.xml</file>
    </files>
  </merge>
  ....

Have a look in that folder and check for the % character somewhere that it shouldn't be. Maybe you're sucking in some kind of file that's not actually XML at all.

Drew Noakes
unfortunately this is the only error message I get :(. So what are the files I should try looking at? Where is the statistics file? Any other files I could look at?
Grzenio
In my builds, the statistics are stored in a file called report.xml and it's stored in the parent folder of the buildlogs. Try opening that file and seeing how it looks at the tail end. Also, if you have multiple builds is this happening for all of them?
Drew Noakes
Hi, finally I got it! (see my response) it took me ages to find though, CCNet could give some more meaningful error tbh.
Grzenio
A: 

One thing to note - if you specify build tasks within the cruise control project, you don't have to specifically tell it to merge the output - it is handled automatically. One method of debugging is to start by commenting out all of the tasks except the first. If that build succeeds, uncomment the next task and try again. You will eventually find the task that is failing and can continue debugging from there.

Pedro
+1  A: 

Finally managed to find the issue: the build used Nant to do most of the task and Nant was configured incorrectly:

  • It was configured to log all the debug information
  • log4net was configured to log something in <> brackets in nant.exe.config

So the build was failing when ccnet tried to merge nant output with build output.

Thanks very much everyone for help!

Grzenio
Glad you got it working.
Drew Noakes