Welcome to
Kenn's Windows Workflow Foundation (WF) Page
Download Source Code:
Source Code Here (Note that this code differs from the book's original code. It's been updated per revisions.)
Errata:
Bugs. I hate them, but I also realize they're a fact of life. If you find a technical error in my Workflow Foundation book, I'd very much like to know about it so that I can make corrections in future editions and reprints. Thank you for reading, and thank you for sending in comments, both good and bad. I read every one!
(Note that as of 4/26/07 a reprint is in the works that will address these issues! I'll keep you posted...)
Here are the known issues:
Multiple workflow runtime instances per AppDomain:
Steve {a reader} writes:
"I hope you don't mind me writing you out of the blue about this title. I have been anxiously awaiting this title so I would have a good book to recommend to the customers I support, as there is no good existing book that I feel is appropriate for the developer that is new to Workflow. We just got a copy of this book in the {location elided} site library and I was the first person to check it out. Unfortunately, within about the first 15 minutes of casual review I spotted many errors, including some that are very significant. One example is on page 28 in the section "Building a Workflow Runtime Factory". This section states that there can only be one instance of a WorkflowRuntime per AppDomain and then devotes several pages toward addressing this issue. This has not been the true since pre RTM (going on 5+ months now). If this book had been released pre RTM and notated with a disclaimer then this sort of thing would be more acceptable. This is just one example; every time I open the book I seem to find more technical errors. (They just seem to jump out at me :) )
"
Well, folks, first let me say that I don't know what "many errors" means, but if they're in the vein of the error he mentions, then the fact is that chapter was originally written in February 2006, well before RTM. If any such pre-RTM errors still exist, which is possible, it's because you can't write a book in a few months. You have to start writing when things are in beta, and in my case, very beta. It took over six months of concentrated effort to write, and then a couple of months to get printed. If you back the timeline up, you'll find that the majority of the book was written while WF was in its earliest stages.
I mention this not as an excuse, but simply as a statement as to how things like this can happen. By the time you're writing Chapter 18, you have to move forward with the belief that things you've written earlier are still true. Where you know things have changed, you most definitely do go back and edit earlier chapters. That happened several times, in fact. This one issue, the ability to have more than one workflow runtime instance per AppDomain, just didn't float to the top as a critical piece of information at the time, and in fact I'd argue that the factory is still a good idea because it neatly cleans up, is a great place to stick initialization information (database-related services and things of that nature), and it makes for a nice way to obtain a running instance.
Nonetheless, Steve is very correct. You can now have more than one instance of the workflow runtime executing per AppDomain, for whatever reason you may want to do that.
DependencyObject as a base class
On page 61: The class MyClass should derive from DependencyObject to participate in the dependency chaining process. As I was writing, I'd copied the code over, modified the property to be a dependency property, and just neglected to add the base class. Editor inheritance at its worst!
Revised code for Chapter 14, Soda Machine
I was never very satisfied with the reset capability of the SodaMachine application from Chapter 14. Since the workflow is a state machine, and since the state machine has a terminal condition, I needed to restart the workflow once a soda was dispensed (unlike a real soda machine, which would return to its initial state to wait for another customer). I did it this way intentionally to show a terminal condition in action, otherwise we'd never use the activity in the book.
In any case, clicking reset attempted to shut the workflow runtime down and recreate it, but this seems to have caused race conditions and all sorts of bad side effects. I spent a lot of time debugging it and never really found a good way to reset the workflow runtime, until now.
The revised SodaMachine code, available here, in a sense hits things on the head with a hammer, but it's a far cleaner way to reset the application than my previous attempts. Now, when you click the reset button, I call Application.Restart, which dumps the current application and starts anew. Perfect for this situation!