State workflow bug
Can anyone else verify this bug?
https://connect.microsoft.com/wf/feedback/ViewFeedback.aspx?FeedbackID=171215
It's very basic - a state workflow won't correctly handle HandleExternalEvent if it's in an EventDriven which is at 'workflow' level, rather than inside a specific state. It will handle HandleExternalEvents if they are inside a state & eventdriven though.
I have an example file if anyone wishes to look.
Thanks for testing: had a problem emailing you though, perhaps GMAIL does not like .ZIP files?
jon.flanders@gmail.com on 16/08/2006 16:44
The recipient could not be processed because it would violate the security policy in force
<myserver.somewhere.com #5.7.0 smtp;552 5.7.0 Illegal Attachment q40si1003760ugc>
Howard - this isn't a WF bug so much as as an assumption they are making about your implementation of the interface. In your implementation you call the event
CustomerHasPaidEvent whereas they expect
CustomerHasPaid. There is an exception being thrown when the ExternalDataExchangeService is hooking up your event handlers. The workflow is getting setup and everything is working fine - but your event is never firing because the eventhandler isn't getting setup. Change the name to
CustomerHasPaidDebt on your implementation of your interface and everything will work.
VB.NET allows this - but as you can see - it isn't really a good way to go :)
I think you means "whereas they expect CustomerHasPaidDebt .."
I see what you mean - the interface and implementation event names have to match up. I had not noticed I'd changed it.
Odd that the EDES does not throw a exception that could be handled.. how did you manage to spot that?
Many thanks either way - WF is back on my to-do list :-)
EDS does throw an exception - its just that it catches it and doesn't consider it "fatal" so it eats it.
Here's how I did it. First - on Tools-Options-Debugging - I disable "Just My Code" (this is the stupidest default they've ever put in VS IMO). Then bring up the exceptions dialog (Ctrl-Alt-E) - select to break on every CLR exception.