Where are the intermediate files?

Mar 5, 2009 at 8:31 PM
We have a few tokens that we put into our Sandcastle project.  Things like the output folder.  We then run a tool on the file to replace the tokens with the appropriate values for that build machine (yes we have several).  I have run into an issue where I get an XmlException on the post processed file (the one with the tokens replaced).  I have compared the two files (the one with the tokens still in and the one with the tokens replaced), and all seems to be fine.  Additionally the error specifies the 645th character on the 82 line of the file.  Obviously the file I wrote does not have any lines with 645 characters.  I assume that the file is transformed (perhaps more than once).  Where can I find the intermediate files so I can identify the invalid character and work back to identifying why it is there?

Pat O
Mar 6, 2009 at 1:29 AM
Hello Pat O,
What really do you want to achieve?
(you may not be doing it right, so please state the actual problem instead of how you are handling it).
...and what tool are you using, if any?

Best regards,
Mar 6, 2009 at 3:25 AM
This sound more like a problem with a transformed file in SHFB's build output.  If so, transfer the discussion over to the SHFB discussion group.  You'll find the intermediate files in the working folder.  This will be the folder specified in the WorkingPath property or, if blank, the .\Working folder in the OutputPath property folder (.\Help\Working by default).  Usually, invalid characters in XML files are caused by unrecognized entities or unencoded characters.  It could be that in your custom transformation tool, you aren't properly handling them when stored in the XML file.

Mar 6, 2009 at 1:55 PM
  I will post my question about the values we are tokenizing on the SHFB discussion group.  I get a little lost in all these different projects :-).

  Thanks I will look there.

Pat O
Mar 6, 2009 at 9:52 PM
I figured this out.  I wrote a tool that reads the SHFB project and write a new project with all the isExposed values reversed.  In this way I can reference the new project with a link type of none.  This removes the warnings about unresolved types.  However, as this is a copy of the original file, it how has an additional reference to itself.  I suspect there is a stack overflow or similar condition that throws the exception I ultimately see as an XmlException. 

So it's my bad.

Pat O