I had a test project that I was using to Unit Test my Windows Workflow activities. Green across the board.

I put all the activities together into a workflow and set up the test for the workflow, but the Output Parameters were always empty.

I put breakpoints in the code. The debugger never stopped at them.

I created a console app to host the workflow and made the EXE for the console the startup app for the workflow project. Several sites said this would enable debugging inside the workflow. Nope! The debugger never stopped inside the workflow.

And the Workflow never terminated, or cancelled, in fact, it seemed to be dying and disappearing. WTF!?!

After much anguish, I looked through every single method and property of my WorkflowManager class and my WorkflowWrapper class. And then I saw it…

The WaitAll method in the Manager class sits around using the manual WaitHandles on the workflows it is managing. When they all complete, the manager returns control to the calling code.

The unit test says:
1) Set up the Manager
2) Set up the Workflow
3) WaitAll(5000)
4) Assert.IsTrue(workflow.OutputParamaters.Count()>0);

I finally (as in DOHN!) realized that the WaitAll method takes a timeout parameter that is in milliseconds. Each activity was tested separately and could complete in less than 5s. The entire workflow, however, needed more time. The WaitAll was dumping out of the thread when the time limit was hit, disposing of the workflow runtime before it could complete and without raising ANY other events. Grrrr…

So, now I have upped the wait time in my test to 120,000 (2 mins) and, lo and behold, the test passes. Grrrr again…

So, just a little tip:

TIP: When debugging workflows, make sure your WaitHandle timeout is set to longer than the combination of the time for the process to execute plus the time you will spend stepping through the debug code, otherwise, the WaitHandle will trigger and dump you out of the WorkflowRuntime before the Workflow actually gets a chance to finish.