I’ve been doing a bit of integration between a group of sequential workflows and a WCF engine service recently. In this particular solution, we’ve used a state machine linked to a number of sequential workflows to get our work done and ease some of the versioning concerns with the current version of WF. We’ve now got a second state machine that manages a similar, but seperate life cycle, and contains some similar sequential workflows (which are named the same, but exist in seperate namespaces).
This should be fine, as the fully qualified name for the workflow will be different. Unfortunately this is not quite true as when I add an If-Else activity I start getting Key not found exceptions!
Unfortunately, even with some pretty explicit custom logging tools this exception is a hard one to pull apart. In the output from the workflow runtime all that can really be seen is a key not found exception in the dictionary on the if else activity. Digging deeper (with the help of an SOS master – thanks Bud!) we found that the key’s loaded into the dictionary were not the keys that should have been there. They were the keys for an alternate sequential workflow by the same name in a seperate namespace…
So what’s going on?
Well when you add an If-Else activity a rules file is generated to contain the conditions you place on the activity branches. When these are compiled they are embeded into the assembly, and at run time the rules are located in the assembly and associated with their activity not by a fully qualified path, but by the activity name alone. Obviously this causes some contention if you have 2 rules files that belong to activities with the same name in different namespaces!
Fixing the issue
The fix is reasonably simple. Change the name of one of the activities right? Well, yes and no. Due to the limted refactoring support in WF you’ll need to not just change the file name but also manually update the activity name in the properties of the activity. This will break things like send or receive activities and other activities that map their values using a path that contains the acitivity name. So you’ll have to go back and re-bind those bits. Once you’re done though and eveything is building again you should be right to rock!