Why does loading xml doc cause TFS build workflow to throw exception?

alexone

New Member
When a TFS 2012 Build Agent executes a workflow with my code activity, am getting exception when attempting to load an MSTest results (.TRX) file for reading/parsing. The .TRX file was created by MSTest in another CodeActivity that was executed immediately prior to this one. It is located on local HDD, in a subfolder of the TFS build agent 'BuildDirectory'. My CodeActivity:\[code\] public sealed class ParseMSTestResults : CodeActivity { public InArgument<string> MSTestResultsFile { get; set; } protected override void Execute(CodeActivityContext context) { string xmlFile = MSTestResultsFile.Get(context); if (!File.Exists(xmlFile)) { throw new UnexpectedErrorException(); } try { // This triggers the problem, but doesn't throw immediately XElement element = XElement.Load(xmlFile, LoadOptions.None); // Same problem as above (if I comment the line above) XDocument doc = XDocument.Load(xmlFile); } catch (Exception ex) { context.Log("Exception thrown: " + ex.Message); } } }\[/code\]The exception caught by my workflow is: "An error occurred while calling tracking participants causing the instance to be aborted. See the inner exception for more details."InnerExcpetion is Nothing, so more info isn't available for me there.Note: I'm intentionally (temporarily) snuffing this exception, to demonstrate that this code itself isn't throwing the observed exception. Or so I believe.Observations:
  • I've narrowed my problem down to the .Load() lines of code. Whencommented-out, my CodeActivity executes fine (just doesn't accomplishmuch).
  • I can successfully execute this code in my unit tests, feeding it .TRX files generated by MSTest. The problems are encountered onlywhen executed in a workflow.
  • Filepath lengths to .TRX file are less than 260 (MAX_PATH)
  • I never see logging message from my catch{} statement, even though I'm using BuildMessageImportance.High in my Log() helper, and mylogging verbosity is at 'Diagnostic'.
  • Some workflow logs show at least one successful execution of this code activity, sometimes two, before the stated exception is thrown. In my workflow, I call this activity at least a dozen times.
 
Back
Top