One of the customers actually told us that the way his system was designed, re-factoring might result into affecting runtime performance since he would need to be passing context across different State Machines. Hence, he would rather take the design time performance hit, than the runtime performance issues.

Well, we have heard these customers. Starting in VS 2010 RTM, the design time workflow performance has been improved drastically across the board. Please find some of the statistics we took recently comparing VS 2008 SP1 and VS 2010 for design time workflow performance.

Custom State Machine Workflow with ~10K lines of Code Besides and ~500 activities

*: Warm scenario is one where you have opened the designer at least once and closed it. So the subsequent opening of the designer in the same VS instance is called a Warm open.

**: Note that the Activity Bind dialog numbers are also similar to what you will notice for Code Handler generation or the Type Browser dialog launch or the Rule Set editor launch.

The final question, you got is, I cant move to VS 2010 right now. Is there a QFE or patch we can apply to VS 2008 SP1? Again, I am really pleased to announce that the answer is a resounding YES. The QFE is now available to the customers here and here(apply them together for maximum benefits!). So go ahead, try the patches on VS 2008 SP1 or move to VS 2010 RTM and see for yourself the tremendous improvements the product team has delivered for WF3 Designers.

Hope this 3 part series helps you in improving the designer performance considerably. As always, ping me if you have any questions/concerns.

Thanks,

Kushal.

To figure out what's wrong, I did an Attach to Process(to debug) with another VS instance to the VS with the workflow designer and turned on all the exceptions. Next, I tried to launch the workflow designer and Whoa…

I am getting hundreds of File IO Not Found Exceptions. No wonder the performance was slow.

I tried compilation of the project to check if the customer is missing something. No, nothing was wrong. The project built successfully. What was happening that directly contributed to the slow designer performance?

The problem is:

If an activity used in a workflow is dependent on Assembly A(uses some types out of A) and Assembly A is dependent on Assembly B; during design time, when you load the workflow, the object instance of each activity in the workflow is created. During this instance creation, CLR wants to ensure that not only the activity assembly, but all its dependent assemblies are loaded(A and B) as well. For this purpose, the VS Type Resolution Service goes through the path where it finds the activity assembly, to look for A and B. It also finally looks up GAC.

If it still doesn't find the assemblies in those paths, then it will do an Assembly.Load for A and B with their partial names. This would mean that if an assembly with Version 1.0.0.0 is not found it will try 1.0.0.1. Similarly, if assembly with culture = neutral is not found, then look for assembly with a specific windows or framework culture. This continues with different variations based on the CLR algorithms for loading assemblies with partial names till they are found. Thus you can imagine the number of File-Not-Founds per assembly and then think about the same with multiple assemblies that are needed and not being found during the workflow design time authoring environment.

Hence, in addition to the tips we talked about in the previous post, please do an Attach To Process to the workflow designer VS instance and see if you have too many File Not Found Exceptions. If so, please ensure the necessary assemblies are in the VS probe path(possibly assembly references in the workflow project or adding to VS(devenv.exe) probe paths) and see if that improves the performance drastically.

In my next post, we will talk about what if none of the solutions we have discussed till date works. Stay tuned!

Thanks,

Kushal.

1. WF3 is the version of Workflow shipped as part of .NET Framework 3.0 and 3.5. Note that WF3 is also shipped as part of .NET Framework 4.0. Meaning, System.Workflow.* assemblies are shipped as part of the latest version of the framework.

2. WF4 is the latest version of Workflows we are shipping first time as part of .NET Framework 4.0. Meaning, System.Activities.* assemblies are shipped for first time in the latest version of framework as well.

Yes, both the versions of WF3 and WF4 are being shipped simultaneously in .NET Framework 4.0.

Now, about the design time performance, yes, we have heard you about the performance issues. In general, the complaint is that the performance of the designers starts decreasing exponentially as the number of activities on the designer starts increasing.

The next few articles, we will talk about how you can improve the performance of the designers as well as see some fixes that we have done to improve the performance.

To start with, one of the white papers about the general Workflow performance has been published in here.

A few other tips to keep in mind to improve the Design Time performance are(initially published in a forum post by Lorenz Prem and Ramraj B):

1. Move all types used in workflows to a different project than where the workflows live.

Move interfaces, event types, custom activities, helper classes to a different project than in which the workflow resides. E.g. in the solution from a customer, there were about 10 project, with 10 workflows each and 10 associated event types. These types are all reparsed to update to build the design time type information every time the user changes workflows in the project. Moving these to a different assembly e.g  just one project with all the types needed for the 10 workflow projects will help improve performance.

2. Reduce the number of workflows in a project.

Each workflow is a type ( directly in c#/vb, and indirectly in xoml case) that needs a design time type to be built by parsing, so if there are 10 workfows in a project, opening any workflow in the project for the first time means parsing all the other workflows as well. Classifying these workflows based on their function and grouping them in 2-3 workflows per project improved performance drastically.

3. Re-Factor large state machine workflows into smaller workflows

One example we found from a customer had 780 states and 1000 activity binds in the same workflow, leading to a InitializeComponent() of about 16000 lines. Factoring this state machine into smaller reusable workflows will making designer performance much better, and reduce a lot of redundant states.

4. Don’t do long running work in activity constructors

Activity constructors are called during design time also, so doing things like connecting to a database etc should never be done in constructors, this can make the designer take too long to open workflow documents using these activities.

Of course, there will be scenarios where the above 4 tips wont solve all/any of your issues with the designer performance. For that, please stay plugged-in for the next few blog posts on this topic:-)

Thanks,

Kushal.

Another scenario would be, how to replace an activity which queries a live Db( or does some other Aysnc work) with a test activity which can query a test Db or even a file during testing.

One way is to load the activity in the designer and then use the MorphHelper class to replace the long running activity with a mock activity. You can then use wd.Flush(wd is an object of type WorkflowDesigner) and then use the wd.Text to save the updated Xaml into a different file to finally unit test the workflow/composite activity.

The cleaner way though, is something that one of the Devs in our team, Dan Glick, suggested.  Instead of loading through the designer and going about multiple steps, the developer/tester can use a custom XamlSchemaContext.

For example: Suppose you want to replace a Prompt activity with an Action activity. Also, to add some complexity to the complexity, assume that Prompt activity has an InArgument<string> UserResponse. However Action has an InArgument<string> but with a different name – UserAction. Meaning, there is no 1:1 correspondence between the arguments/properties between the two activities.

To achieve this replacement, we can write something as follows:

    public class MySchemaContext : XamlSchemaContext
    {
        public override XamlType GetXamlType(Type type)
        {
            if (type == typeof(Prompt))
            {
                return new myXamlType(typeof(CustomActivities.Action), this);
                //return base.GetXamlType(typeof(CustomActivities.Action));
            }
            else
            {
               return base.GetXamlType(type);
            }
        }
    }

    public class myXamlType : XamlType
    {
       

        public myXamlType(Type t, XamlSchemaContext schemaContext):base(t, schemaContext)
        {
            

        }

        protected override XamlMember LookupMember(string name, bool skipReadOnlyCheck)
        {
            //return base.LookupMember(name, skipReadOnlyCheck);
            if (name == "UserResponse")
            {
                return base.LookupMember("UserAction", skipReadOnlyCheck);
            }
            else
            {
                return base.LookupMember(name, skipReadOnlyCheck);
            }

        }

    }

With these two helper classes in place, we now get the new activity object tree that can then be passed to a runtime host and thus unit test the workflow/activity successfully.

Activity act = ActivityXamlServices.Load(new XamlXmlReader("myFile.Xaml", new MySchemaContext()));

Hope this helps!

Thanks,

Kushal.

Currently, we don't have a clean solution to this as the ActivityDesigner has an implicit style which is picked up by WPF. And if there is such an implicit style, the App.Resources style in our application never gets picked up.

The workaround that we have suggested is to create a simple DerivedDesigner from ActivityDesigner and then apply it on for all types that are using just the ActivityDesigner. This has to be done after loading the Workflow though rather than in the RegisterMetadata section.

AttributeTableBuilder table = new AttributeTableBuilder();
table.AddCustomAttributes(typeof(Activity), new DesignerAttribute(typeof(DerviedDesigner)));
MetadataStore.AddAttributeTable(table.CreateTable());

Hope this helps!

Thanks,

Kushal.

This can be accomplished through the ViewStateService. We already use the ViewStateService per activity to store the Expand/Collapse state of the activity. An additional item in the ViewState dictionary would be its unique identifier. So every time an activity is added to the designer surface, we can do the following in the OnModelItemChanged(fired when the activity is added the first time to the designer) event handler.

this.Context.Services.GetService<ViewStateService>().StoreViewState
(
     this.ModelItem, "myId", i++
);

As you persist this Xaml, you would see something like below for a leaf activity:

<sap:WorkflowViewStateService.ViewState>
   <scg:Dictionary x:TypeArguments="x:String, x:Object">
        <x:String x:Key="myId">22</x:String>
   </scg:Dictionary>
</sap:WorkflowViewStateService.ViewState>

Hope this helps!

Thanks,

Kushal.

The customer wanted a way to hide the breadcrumb. Since we didnt have a specific API to do so, we just asked him to do the following:

FrameworkElement e = this.wd.View as FrameworkElement;
e.Margin = new Thickness(0, -40, 0, -40);
grid1.Children.Add(this.wd.View);

We just moved the Designer View up such that it hides the breadcrumb panel at the top.

Hope this helps!

Thanks,

Kushal.

Good news though, it is not that difficult. As we create our ActivityDesigner, we essentially need to add the following property:

<sap:ActivityDesigner.Icon>
        <DrawingBrush>
            <DrawingBrush.Drawing>
                <ImageDrawing>
                    <ImageDrawing.Rect>
                        <Rect Location="0,0" Size="25,25" ></Rect>
                    </ImageDrawing.Rect>
                    <ImageDrawing.ImageSource>
                        <BitmapImage UriSource="Activity-Monitor-icon.png" ></BitmapImage>
                    </ImageDrawing.ImageSource>
                </ImageDrawing>
            </DrawingBrush.Drawing>
        </DrawingBrush>
</sap:ActivityDesigner.Icon>

Hope this helps!

Thanks,

Kushal.

However, what if you have your custom control and you want to bind the changes on the designer surface with that specific custom control.

For example, you have a WPF Textbox in your application and you want to bind the changes to the ‘DisplayName’ property of your selected activity with this ‘Textbox.TextProperty’.

Solution:

this.wd.Context.Items.Subscribe<Selection>(delegate(Selection selection)
{
       Binding myBinding = new Binding();
        myBinding.Path = new PropertyPath("DisplayName");
        myBinding.Source = selection.PrimarySelection;
        myTextBox.SetBinding(TextBox.TextProperty, myBinding);

});

Hope this helps!

Thanks,

Kushal.

This can now be achieved pretty simple:

modelItem.Focus();

Thus, once you know the model item you want to access, call modelItem.Focus and this should bring it in view and set focus on it.

Another interesting thing that happened when I was cooking up this sample :Essentially, I had a custom designer for an activity with a button on it. In the button click event handler, I was getting hold of the activity’s model item and then:

 using (ModelEditingScope editingScope = this.ModelItem.Root.BeginEdit("Activities"))
{
        this.ModelItem.Root.Properties["Activities"].Collection.Add(new Sequence());
        //Do this multiple times to have scrolls introduced in the designer due to the large workflow size

}

Then to set the focus on my activity with button, I did: this.ModelItem.Focus(). However this didn't work. The focus still remained on the last Sequence activity added. The trick was actually to do it this way:

 Dispatcher.Invoke(DispatcherPriority.ApplicationIdle, (System.Action)(() =>
 {
        myItem.Focus();
  }));

The reason being, the added model items themselves set the focus on them through an idle. Hence we need to queue up our idle after them. Hence the Dispatcher.Invoke with the action on ApplicationIdle.

Hope this helps!

Thanks,

Kushal.