Partager via

State machine workflow with delay activity

  • Article

State based workflow that has a DelayActivity. The DelayActivity never fires and errors out eventually. The problem lies in the fact that the workflow calls out to another DLL in the code activity following the DelayActivity. When the call is made a "System.IO.FileNotFoundException: Could not load file or assembly" exception is raised.

System.IO.FileNotFoundException: Could not load file or assembly 'Utilities, Version=1.0.0.0, Culture=neutral, PublicKeyToken=584ac65395d6cc3f' or one of its dependencies. The system cannot find the file specified. File name: 'Utilities, Version=1.0.0.0, Culture=neutral, PublicKeyToken=584ac65395d6cc3f' at RRURequestWorkflow.Workflow1.codeActivity2_ExecuteCode(Object sender, EventArgs e) at System.Workflow.ComponentModel.Activity.RaiseEvent(DependencyProperty dependencyEvent, Object sender, EventArgs e) at System.Workflow.Activities.CodeActivity.Execute(ActivityExecutionContext executionContext) at System.Workflow.ComponentModel.ActivityExecutor`1.Execute(T activity, ActivityExecutionContext executionContext) at System.Workflow.ComponentModel.ActivityExecutor`1.Execute...

Go ahead and start Windows Sharepoint Services Timer. This will resolve the issue.

Reason behind this

----------------------------

When you have workflow that has got a delay activity, the event is fired by the service(SPTimerV3), before it fires, it has to load the assembly from its bin or from the GAC, only one file(module loads) based on the assembly information specified in workflow.xml file loads.

Deploying the new binary after changing the workflow activities, the SPTimerV3 is not aware of the newly added binary, it won’t reload it unless you do a time reset.

Unless you do a reset, the persistence (serialization or de-serialization) or loading of assembly would fail due to mismatch of types.

Comments