standard beta disclaimer.  This is written against the beta1 API’s.  If this is 2014, the bits will look different.  When the bits update, I will make sure to have a new post that updates these (or points to SDK samples that do)

In WF3, we allowed our customers to rehost the WF designer inside their own applications.  This has many reasons, usually about monitoring a workflow or allowing an end user to customize a constrained workflow (visual construction of an approval process, for instance). This article became the gold standard for writing rehosted applications.  As we were planning our work for the WF4 designer, this was certainly a scenario we considered, and one we wanted to make easier. 

This post consists of a few parts

• Designer architecture – introduce the pieces, parts and terms we’ll use throughout
• Simple rehosting – getting it up and running
• What to do next

Designer Architecture

There are a few key components here

• Source
  • In VS, this is xaml, but this represents the durable storage of the “thing” we are editing
• Instance
  • This is the in memory representation of the item being edited.  In vs2010 for the WF designer, this is a hierarchy of System.Activities instances (an object tree)
• Model Item Tree
  • This serves as an intermediary between the view and the instance, and is responsible for change notification and tracking things like undo state
• Design View
  • This is the visual editing view that is surfaced to the user, the designers are written using WPF, which uses plain old data binding in order to wire up to the underlying model items (which represent the data being edited).
• Metadata Store
  • This is a mapping between type and designers, an attribute table for lack of a better term.  This is how we know what designer to use for what type

I’ll go into more detail about these pieces and parts in future posts as well, but this is the mental model of the things I will be talking about as we go through the designer.

Stay tuned, part 2 will come tomorrow!