Saturday, March 23, 2013

SharePoint task: something went wrong, ArgumentNullException

For SharePoint site with custom security settings (end users may or may not know this), user may get the "Sorry something went wrong" general error when trying to access a workflow task that's assigned to the user (e.g. clicking the task link in the reminder email).  The following was logged:

3/23/2013 09:33:51.92  w3wp.exe (0x1444)                        0x0A50 SharePoint Foundation          Runtime                        tkau Unexpected System.ArgumentNullException: Value cannot be null.  Parameter name: item    at Microsoft.Office.Workflow.ListPage.SimpleNameFromItem(SPListItem item)     at Microsoft.Office.Workflow.WrkTaskIPPage.OnLoad(EventArgs ea)     at System.Web.UI.Control.LoadRecursive()     at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) 859d0a9c-fb6c-0023-bd9a-727c80fdb7cb
This is typically due to that the user does not have proper permissions on the list item that the workflow task is tied to.  In addition to "View" permission, user must have "Approve Items" in order to perform an Approve task on a list item.  Depends on the custom security model, additional security may need to be given directly on the list item (if unique item level security is used), or given to the user/group.

Thursday, March 14, 2013

SharePoint Workflow CreateTaskActivity and OnTaskChangedActivity must be one-to-one mapping

In a Visual Studio workflow for SharePoint 2010, if you have a series of complex logic that check various conditions to determine what to do if a task is completed, you may be tempted to put in multiple OnTaskChanged activities with the token tied to the same CreateTask activity.  I have recently tried that.  The flow of the workflow looks pretty clear and natural visually.  It built and deployed successfully and started and executed the steps successfully until it hit the second OnTaskChanged.  The Workflow History logged "An error has occurred in ", and the SharePoint log logged this error:

Error in commiting pending workflow batch items: System.ArgumentException: 0x80070057     at Microsoft.SharePoint.Library.SPRequestInternalClass.RegisterEventReceiver(String bstrUrl, String bstrListName, EventReceiverOperation operation, Guid guidId, String bstrName, Guid guidSiteId, Guid guidWebId, Guid guidHostId, Int32 dwHostType, Int32 dwSynchronization, Int32 dwType, Int32 dwSequenceNumber, String bstrRemoteUrl, String bstrAssembly, String bstrClass, Guid solutionId, String bstrData, String bstrFilter, Int32 dwCredential, Guid contextObjectId, Guid contextType, Guid contextEventType, Guid contextId, Guid contextCollectionId)     at Microsoft.SharePoint.Library.SPRequest.RegisterEventReceive.....

THe bottomline is, put one OnTaskChanged activity in a While activity.  With a couple of IfElse in there, the workflow would look confusing visually, but it would work fine at runtime.

Saturday, March 9, 2013

FileNotFoundException after SharePoint workflow DelayActivity

I noticed that a SharePoint 2010 workflow that's deployed to my dev SharePoint farm kept logging " failed to run" in the Workflow History after every so often.  Turned out that every time the Delay Activity comes out of its time out, this error is logged.  The workflow is stuck forever in the In Progress status though.  Found in the SharePoint ULS log the following everytime this happened:

03/09/2013 20:50:13.76  OWSTIMER.EXE (0x09F0)                    0x20E0 SharePoint Foundation          Legacy Workflow Infrastructure 75yn Unexpected Load Workflow Assembly: System.IO.FileNotFoundException: Could not load file or assembly 'My.Content.WF.ClientReview, Version=1.0.0.0, Culture=neutral, PublicKeyToken=1f310f3d9eb1728b' or one of its dependencies. The system cannot find the file specified.  File name: ''My.Content.WF.ClientReview, Version=1.0.0.0, Culture=neutral, PublicKeyToken=1f310f3d9eb1728b'     at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)     at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, S... 1746069c-9c8e-2075-8ca7-47e33a38cd91
So what was going on?  My workflow only references SharePoint assemblies, and itself is indeed in the GAC.  A closer look shows that this was thrown from OWSTIMER.EXE.  So it's the timer job service.  Apparently the Delay Activity relyies on the timer job service to fire.  Just like w3wp.exe, it needs a restart to recognize newly changed assemblies in the GAC.  Sure enough, I restarted the timer job service, started a new WF, and the Delay Activity fired successfully after coming out of its timeout.