Thanks for the information. This practise, however...

2008-12-05T10:01:00.000Z

Thanks for the information. This practise, however, is not intended for tracing but for adding unhandled exception details only into the history log, which would occur when the workflow encounters a breaking error, causing it to terminate.

I would not recommend using this for trace information - any information that is not directly usable to an end user should go into a real trace file, not the history list.

One of the issues my company opened with Microsoft...

2008-12-05T09:36:00.000Z

One of the issues my company opened with Microsoft was closed with a work-around that says: Don't pollute your workflow history list with lots of trace information. Having more than 2000 entries in a workflow history list (especially one shared by multiple instances of the same workflow in the same list) is "not a best practice". It lead to what we now call the "stuck workflow" problem. I now write the bare miminum of trace information to the workflow history log and write my trace entries to a dynamically created Discussion Board topic. The problem with writing to the workflow history list is worse because workflow history lists are hidden by default and cannot be "pruned" to keep them below the recommended 2000 or less entries.

Comments on Tobias Lekman - Blog: Workflow Extensions and Item Template for Debuggin...

Thanks for the information. This practise, however...

One of the issues my company opened with Microsoft...