Problem: The Time Required to Open a Workflow Document Is Too Long
The Workflow designer relies on parsing the source code in the current project to provide updated design information in various locations, such as the workflow design surface and the rules dialog intellisense. This enables the Workflow designer to reflect changes in source code before the project has been rebuilt.
Tips to Make the Designer Perform Better
The following tips can improve the performance of your Workflow designer.
| Tip | Explanation |
|---|---|
Move all types used in workflows to a different project than where the workflows live. |
All interfaces, event types, custom activities, and helper classes are reparsed to update the design-time type information every time you change workflows within a project. For example, consider a solution with 10 projects, 10 workflows in each project, and with 10 associated event types. Moving the event types to just one project helps improve performance. |
Reduce the number of workflows in a project. |
Each workflow is a type (directly in the case of C# and Visual Basic, indirectly in the case of XAML) that needs a design-time type to be built. Thus, if there are 10 workflows in a project, opening any workflow 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 improves performance drastically. |
Refactor large state machine workflows into smaller workflows. |
Factoring state machines into smaller reusable workflows improves designer performance by reducing the number of redundant states. |
Avoid putting long-running work in activity constructors. |
Because activity constructors are called during design time, putting long-running work items, such as connecting to a database, into the constructors can make the designer take too long to open workflow documents. |