We are persisting all of the WF4 workflows we create with our rehosted Designer in a SQL Database and are reloading them all when needed via _WorkflowDesigner.Load(xamlString). That is working well in general.
But for custom activity types defined in a custom ActivityLibrary which has had certain types of changes since the workflow XAML was originally persisted, the Designer control will substitute a ModelItem based on "ErrorActivity" during an attempt to
reload that XAML in the rehosted Designer. This may occur if the argument requirements of the type have changed, if the type either is no longer in a a newer version of the loaded activity library, etc.
This situation would be easy enough for the Designer's end-user to fix if they knew the details of the original activity which has been replaced (type, argument declarations and assignments, etc.). In many cases they can just delete the error
activity, drag-and-drop a replacment of the same type with the new signature, hook it back up in terms of In- and Out- arguments, and move on. But it's difficult getting the details of the activity which has been replaced.
We use the common practice of publishing a ValidationErrorService which displays any validation errors in a ListBox. In the above ErrorActivity substitution s
View Complete Post