views:

128

answers:

2

I know the calls are going out, as I've used an incremented variable to track it. But some just never make it to the output window. Is this a known issue? Is there a workaround?

Similarly, breakpoints in the workflow are very unreliable. Stuck with this?

A: 

For brakepoints to work you need to make your workflow project the startup project. If it's a dll use the debug startup application to get it running.

No clue about the Debug.WriteLine. Could it be the trace listener is dropping data because of multi threaded locking?

Maurice
There is only a single project in the solution, but the project was created as a wcf service. I'm not sure if this makes a difference. In any case, breakpoints do get hit, but not consistently. This seems to be a problem other developers here have had on other workflows.How would multi-threaded locking come into play with Debug.Writeline?
Brian
If there are multiple thread writing to the same trace listener it might get into threading issues because there is only a single console. The WF runtime uses the ThreadPool to execute activities.
Maurice
A: 

On the issue with break points not being hit, it usually is because the refactoring folder (obj folder) is out of sync with the workflow designer. One way around this is to close Visual Studio completely (all instances if you run several like me), then in Windows Explorer navigate to your project folder and delete the obj folder. Then open up your solution again and do a re-build.

I've had that happen to me several times, and the way around it was the above trick.

arabian tiger
I'll have to see if that helps. I've gotten in the habit of blowing out the obj folders from past experience with strange behaviour. It's something they *really* need to fix.
Brian