BlueIntegrator provides numerous means of debugging errant Workflows.
(1) New Instance Debugging. You can simply use the Debug | Start menu item in Visual Studio for Applications to kick off a new Workflow Instance and attach the debugger to it. Note that this won’t use the latest VSTA code but the saved version of the Workflow itself. You’ll be prompted to specify file locations for all incoming and outgoing Messages. This is normally the best way of testing your Workflow prior to deployment. When running in this mode you can use both VS.Net trace functionality, and even good old
System.Windows.Forms.MessageBox. You cannot of course use MessageBox in a live Workflow Instance.
(2) Isolation. Always try and get the cleanest possible scenario for debugging. Stop all non-essential Workflow Instances and processes to minimize the noise whilst you are trying to rack down your problem.
(3) Tracking. You can get a lot of information by enabling the various Tracking options on the Workflow Binding, and then using BlueIntegrator Tracking to view this information. Note that to track Messages and Variables, the relevant Tracking option needs to be selected both on the Binding and on the Message / Variable itself (as shown below).
(4) Tracing. Tracing is generally easier than debugging. Write out all the information you can from within your Workflow, either using
ThisWorkflow base method
Log, or a proprietary tracing solution (e.g. a file). VS.Net trace functionality will not work with a running Workflow unless you are attached to a debugger. Base method Log logs to the Windows event log and to the BlueIntegrator tracking log.
(5) Workflow Instance Debugging. You can watch the live state of a Workflow and attach Visual Studio for Applications using the Debug button on the Workflow Instance views. We recommend always enabling the Track all State Transitions option on the Binding before proceeding down this route.