Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

SharePoint Designer 2010 Errors were found when compiling the workflow. The workflow files were saved but cannot be run. Unexpected error on server associating the workflow.


View products that this article applies to.

Symptoms

When attempting to publish a SharePoint Designer 2010 workflow that is large or uses multiple Start Approval Process actions, an error indicating that the workflow cannot be published will be displayed.

In SharePoint 2010 RTM:
  • SharePoint Designer will show the following error: “Errors were found when compiling the workflow. The workflow files were saved but cannot be run. Unexpected error on server associating the workflow”
  • And the following message will be logged to ULS: “w3wp.exe SharePoint Foundation Workflow Infrastructure Medium Workflow Compile Failed: Thread was being aborted.”

After installing the February 2011 CU:

  • SharePoint Designer will show the following error: “Errors were found when compiling the workflow. The workflow files were saved but cannot be run. Unexpected error on server associating the workflow”
  • And the following message will be logged to ULS: “w3wp.exe SharePoint Foundation Workflow Infrastructure Medium Workflow dll failed to compile because it exceeded UserDefinedWorkflowMaximumComplexity of 7000”

↑ Back to the top


Cause

This problem is caused by the large number of Types that are created during workflow compilation, for workflows with many local workflow variables. It is more common for workflows with multiple Approval Process actions, as each preconfigured Approval Process Action comes with a large set of local variables, for the different configurable property of the Approval Process.

Prior to the February 2011 CU, limits on the complexity of the workflow definition were enforced by the Microsoft .NET 3.0 workflow compiler. With the February 2011 CU, SharePoint uses the SPWebApplication UserDefinedWorkflowMaximumComplexity property to enforce a maximum number of Types in the workflow definition, and prevent compilation in these cases.

↑ Back to the top


Resolution

First, make sure SharePoint Farm is at February CU or later build, the following property will be made available:

UserDefinedWorkflowMaximumComplexity

Please refer to the link below for more information:

http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebapplication.userdefinedworkflowmaximumcomplexity.aspx

By installing a CU that includes the server February 2011 CU, SharePoint administrators are now able to prevent compilation of workflows whose compilation would affect the performance of the farm. The default value of the property is 7000, but can be changed based on the needs and profile of the SharePoint farm.

The following PowerShell script can be used to adjust the value per SPWebApplication:

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")

$new_limit = 5000;

$webapp = [Microsoft.SharePoint.Administration.SPWebApplication]::Lookup(http://WebAppURL)

$webapp.UserDefinedWorkflowMaximumComplexity = $new_limit

$webapp.Update()

To give context to the default 7,000 value a Start Approval Process action contains 1176 nodes, a Start Feedback Process action contains 1010 and an empty Start Custom Task Process contains 13 nodes.

Please note, up to certain number, roughly 10000, the compliation will be restricted by Microsoft .NET 3.0 workflow complier so the workflow size still has a ceiling.
At that point, the larger workflows need to be restructured to either have more reusable pieces, or be broken out into smaller individual small workflows.

Some ways in which the complexity of larger workflows can be reduced include:
  • Use light weight workflow actions to replace Start Approval Process action, for instance, Start Custom Task Process action or Collect Data from a User
  • Add new task process variables only as they’re needed
  • When the task approvers (or task email) need to change based on conditions in the workflow, use a conditional block to save the task approver (or email contents) in a local variable and then use a single Approval Process action, rather than having a separate Approval Process actions with hardcoded approvers/email contents in each branch of the conditional block
  • When using the small workflows approach, keep the second workflow into a paused state by using an action like Wait for Field Change. In the first workflow, once the Start Approval actions have been completed the workflow can modify a column which the second workflow is monitoring and then it will come out of the paused state and go on

↑ Back to the top


Keywords: kb

↑ Back to the top

Article Info
Article ID : 2557533
Revision : 1
Created on : 1/7/2017
Published on : 12/27/2012
Exists online : False
Views : 1180