Note: this one I meant to talk about this for a long time.  After this, I actually ran out of immediate topics for WF.  So any suggestions are welcomed.

Back in July, we received a customer request that IActivityTemplateFactory does not work anymore after he installed .Microsoft .NET Framework 4 Platform Update 1 (KB2478063).  It was the first issue we saw after the Platform Update shipped, and I was more nervous than others, because I was the primary dev for the WF activity/designer at that time and fixed the majority of the bugs.  I wasn’t sure if I just introduced a recall-scale bug.  I was on the servicing loop at the time so after some initial investigation, I was tasked to find out the root cause.

In the customer’s scenario, he has a rehoster with a Flowchart as a root.  The rehost app has a Flowchart as the root activity.  He also created an IActivitytemplateFactory which would place two connected flownodes in the FlowchartDesigner:

   1: Activity IActivityTemplateFactory.Create(DependencyObject target)

   2: {

   3:   ActivityDesigner designer = target as ActivityDesigner;

   4:   FlowStep step = new FlowStep();

   5:   Assign assign = new Assign();

   6:   step.Action = assign;

   7:   FlowDecision decision = new FlowDecision();

   8:   step.Next = decision;

   9:   designer.ModelItem.Properties["Nodes"].Collection.Add(step);

  10:   designer.ModelItem.Properties["Nodes"].Collection.Add(decision);

  11:   ModelItem decisionItem = designer.ModelItem.Properties["Nodes"].Collection[1];

  12:   ModelItem stepItem = designer.ModelItem.Properties["Nodes"].Collection[0];

  13:   return null;

  14: }

So far so good right?  And you wouldn’t expect any problem when you drag this Factory to the Flowchart right?  Try this on your own!

If you have PU1, you would discover that the drag operation would throw an ugly ArgumentOutOfRangeException at line 3:

   1: designer.ModelItem.Properties["Nodes"].Collection.Add(step);

   2: designer.ModelItem.Properties["Nodes"].Collection.Add(decision);

   3: ModelItem decisionItem = designer.ModelItem.Properties["Nodes"].Collection[1];

This was surprising – you would expect the “1” index would return the FlowDecision ModelItem but it throws an Exception instead.  Then we tried to look at the Collection.Count at Line 3 and we discovered that FlowDecision node was not inserted:

   1: designer.ModelItem.Properties["Nodes"].Collection.Add(step);

   2: designer.ModelItem.Properties["Nodes"].Collection.Add(decision);

   3: Debug.Assert(designer.ModelItem.Properties["Nodes"].Collection.Count == 2);

Guess what the Collection.Count is: 2? 1? No… it’s ZERO!  So it appeared as if nothing was inserted into the collection!  As we debugged the return value of Collection.Add, it was not null and was a ModelItem that wrapped around the FlowNode that was inserted to the FlowchartDesigner.  As this moment, I realized that the it was actually caused by a fix we did for PU1.  But before that, let’s give you some background.

The ModelItem object model provides an API which merges multiple ModelItem operations into a single unit of work – you can consider EditingScope as a transaction, where all the changes are not committed until you declare EditingScope.Complete().  Inside an EditingScope though, any ModelItem operation would not change the state of the object model, until Complete is called.

However, if you try to drag this composite FlowNodes to a Dev10 RTM Flowchart and then undo, you will observe that only the FlowDecision is undone, but the Assign remains in the Flowchart.  That’s because the Drag operation is not wrapped inside an EditingScope.  So each ModelItem operation is independent.  Even though it appeared as if you dragged one item to the Flowchart, there were multiple operations (what we called UndoUnit).

Normally, this is not a blocking issue.  However, we found another problem later – if you drag an Activityto the edge of a Flowchart, this drop operation would automatically expand the Flowchart to be big enough to contain the dropped Activity.  Now, if you try to undo it, you will realize that the drag operation is undone, but Flowchart still has the expanded size.  This problem eventually became more annoying with StateMachine, and we eventually decided to fix it by wrapping the drap-drop operation inside an EditingScope.

So far so good… now there is only one UndoUnit for drag-drop operation and the size would be restored properly.  What we didn’t realize was that there were customers who had dependency on ModelItem state, and this fix would break their rehost app.

Wrapping the drag-drop operation into a single EditingScope is still the right thing to do.  And if you are a WF ModelItem developer, you might already see that the customer’s code is not the only way to solve the problem.  Eventually, we recommended the customer to workaround this problem by not depending on Count of Indexes on the collection, but operate on the return value of the Add operation instead:

   1: ModelItem decisionMI = designer.ModelItem.Properties["Nodes"].Collection.Add(decision);

   2: ModelItem stepMI = designer.ModelItem.Properties["Nodes"].Collection.Add(step);

And a single advisory for all WF designer developer:

In IActivityTemplateFactory, do not rely any property or index values of any ModelItemCollection or ModelitemDictionary, because the caller might be in an EditingScope.

However, this behavior is unacceptable, and in Dev11 we have enough new WF functionalities such that the drag-drop can still be in ONE EditingScope, but all the Add/Remove would change the state of the Collection!  Isn’t that wonderful?  A very smart dev called Tony Tang has completed this work and you will see this in Dev11!

Anyway, it is a small fix, but it was interesting (I think) nevertheless, so I wanted to write this story down.

Now, I really need to think hard what I should write next…

Earlier last week, Tim sent me a forum post about asking why State is sealed.  However, I searched around the web and did not find an answer for this.  It is strange because sealing (“shipped”) activity is almost like the first thing that I learned.  So I dug up some internal docs and found the answer:

42.

…

Sorry it is a cold joke; there is indeed a less cold reason for sealing activity thought.  It is really a philosophical decision: We expect that Composition is much better extension mechanism than inheritance.  However, there are also some very valid reason for not allowing State to be extensible.  For one, State is only an artifact that is relevant to StateMachine, so we want to make sure that only StateMachine can consume State.  Also, unlike other activity, State scheduling is tightly integrated with State (that’s why it’s not an Activity).  It would not make sense to allow State to be extensible, because StateMachine would not know how to schedule anything in State other than Entry and Exit.

(Aside of being philosophical, the one valid reason that I can think of where this might make sense, is when an ISV provides a set of out-of-box “composite” states to a StateMachine rehoster.  However, the ISV wants to “seal” the users from changing the State or hide them from the complex logic in this composite state.  In this case, making State “inheritable” would make sense - Microsoft can’t seal it because ISVs needs to seal it.  A little bit ironic, but nevertheless, this would be valid.)

The recommended approach, however, is still to use a composite activity and make it available to user via IActivityTemplateFactroy. There is a catch though.  The IActivityTemplateFactory.Create return an Activity instance.  Normally, that would not be a problem, since most control flow activities (i.e. Sequence, Flowchart) accept an activity as a part of its children activities.  However, StateMachine activity is composed by State, and State is not an Activity.  So you cannot really returns an Activity in IActivityTemplateFactory.

Even if you create an “empty” Activity in IActivityTemplateFactory, you would not be able to drop it into a StateMachine, because StateMachine designer would accept only State.

Does it mean that you cannot create an out-of-box composite State for our ISV customer? --–screaming!---

Well the answer is NO, so don’t panic yet.  What it means, is that you cannot drop a custom composite state from Toolbox to the StateMachine (and I guarantee you that it will be fixed in VS vNext).  However, you can still add a composite state via. the ModelItem level though.

Assume that you’re creating your own rehost, when you are initializing the StateMachine, cache the StateModel modelItem.

private void AddDesigner()
{ 
    this.workflowDesigner = new WorkflowDesigner();
    Grid.SetColumn(this.workflowDesigner.View, 1);

    ActivityBuilder builder = new ActivityBuilder();
    builder.Implementation = new StateMachine(); // 
    this.workflowDesigner.Load(builder);
    ModelItem builderRoot = this.workflowDesigner.Context.Services.GetService<ModelService>().Root;
    
    // NOTE: you need cache the StateMachine modelItem for later use
    stateMachineModelItem = builderRoot.Properties["Implementation"].Value;
}

Then we would add a button to the rehost.  The button is used for adding the composition state to the cached StateMachine.

private void Button_Click(object sender, RoutedEventArgs e)
{
    stateMachineModelItem.Properties["InitialState"].SetValue(null);

    State s = new State()
        {
            DisplayName = "Custom State",
            Entry = new WriteLine()
            {
                    Text = new InArgument<string>("Hello world")
            }
        };
    stateMachineModelItem.Properties["States"].Collection.Add(s);
    stateMachineModelItem.Properties["InitialState"].SetValue(s);
}

In this case if you press the button, you can see the “custom state” in the rehost.

Let me know if it helps

• Remain in the current state
• Jump to a Fault-Handling state and complete the workflow gracefully and restart again.

However, there is no built-in fault-tolerant mechanism in StateMachine.  And there are very good reason for that.  One, we want to keep StateMachine simple (so it is as easy to understand as Flowchart).  Secondly, we really want all the movements within a StateMachine to be driven by Transitions – so if you do implement some fault-handling mechanism, you should be able to draw it in a State diagram and implement it.

Long ago, I did a very small doc on fault-handling.  Assuming most of the heavy-lifting of StateMachine happens in Trigger, you can put a Try-Catch in a Trigger and then StateMachine scheduling mechanism should do all other things for you (so you don’t need to schedule activity yourself.

Fault Handling Pattern for Non-Shared Receive/SendReply transition using Try-Catch Handler by adding a Shared Trigger transition

Step 1: Create a boolean value with “True” default value. Encapsulate a Try-Catch to the current operation in the Trigger. In the original “Condition” section, specify the boolean variable there.  Under normal condition, this variable should always be true, so the State would transition out as normal.
Step 2: In the Catch block, you define the Exception that you want to catch, and also the error-handling logic.  The boolean variable would be assigned to ”false”. So if an exception happened, the boolean variable would be ‘false’.  In this case, no transition would happen and the StateMachine would remain in the current State
Optional Step 3: If you want the StateMachine to transition to an error handling state, then you simply create a shared triggered transition out of the current state.  In this Transition, the condition if the negation of the boolean variable.  So it would transition out if an Exception occurs!

The good thing about this approach is that you can re-use the execution mechanism to prevent a StateMachine from transition.  The constraint though, is that it requires your Trigger to be non-shared.  I would imagine that this approach would be more useful in Workflow Service scenario (where each “Receive” activity is its own transition). 

However, if you already have a shared trigger and you want to handle error this transition, what can you do?  The most elegant way that I could think of (at the same when I was drafting it) was to use an intermediate state to catch the error:

Fault-Handling Pattern with Shared Trigger with one Receive and Multiple Fault-Handling SendReply by Using Null Trigger

Between the original Source and the Destination State, create two State: 1. One "immediate" state designed to evaluate the result of the Action 2. Another "fault-handling" state that could be the destination of the "immediate" state
Within the original transition, if we want to handle any potential fault from Transition.Action activity: 0. encapsulate any activity with a Try-Catch activity 1. In the Catch block, have an "Assign" activity that would set a flag to false (NOTE: because this flag must be shared between two states, it has to be declared at the StateMachine level) 2. The Transition is target at the immediate "Verifying state"
Within the Fault-Decision State: 1. Create a Null-Trigger transition, that would transition to original Destination state if the result is "true" (by default) 2. If the flag is evaluated to "false", transition to the Fault-Handling (i.e "Bad State", or event the original State)

See if these patterns would be helpful to you!

Isaac @ Shanghai

After working in Microsoft for almost 3 years, finally I decided to get my own blog to celebrate my first important work at ADX in China.  But searching through the setting I cannot see any place that allowed me to click the “Create Blog” button!

Reminder: I was later reminded that only Microsoft FTE can create a MSDN blog, so this blog is probably not that interesting to everyone. 

Searching online, I found this article from another softie and it was helpful so I thought I should share it as well.

Create a MSDN blog

1. Go to https://blogs.msdn.com/create-blog.aspx
2. In Blog Name, you have your once-in-a-lifetime chance to specify a name for your blog.  It is going to the address for your blog (i.e. blogs.msdn.com/b/your-specified-name).  However, I created my first blog by typing a random name and realized that a MSDN blog is not removable!
3. After clicking the Create button, you would get your own blog!

However, MSDN blog is not as manageable as other blogging services like WordPress.  And it is unimaginable that anyone would not use a blog editor to post blog.  For that matter, Windows Live Writer comes to my mind as the natural choice.  However, trying to hook WLW with MSDN blog is not as easy as 1-2-3.

When I tried to add MSDN blog account to WLW as “Other Services”, it prompted me for: