1
votes

I have a custom Sharepoint workflow activity created in Visual Studio that works and logs properly in my test environment but fails in production with a generic "Error Occurred" message in the Workflow History list.

In order to debug the activity (since remote debugging against production is a last resort), I implemented step-by-step logging to the Workflow History List to see at what point it was failing, only to discover that it seems to be reaching an error state before the first logging occurs. I had been using a try-catch to capture the exception and log it to the list as well. Still no logging in the history list.

At this phase, logging was done with the following code:

SPWeb spWeb = (SPWeb)__Context.Web;
SPWorkflow.CreateHistoryEvent(spWeb, this.WorkflowInstanceId, 0, spWeb.CurrentUser, new TimeSpan(), "Update", "message here", string.Empty);

where spWeb is the workflow context's Sharepoint Web. Once again, this works in test.

The next step was to use fault handling with a generic Exception type and Sharepoint's LogToHistoryList activity. No dice. I also tried the fault handling option outlined at http://www.sharepointsecurity.com/sharepoint/sharepoint-2007-development/fault-handling-in-sharepoint-workflows/ with the same generic "Error Occurred" result and no other logging in the History list.

My questions, then, are 1) Does anyone know what would cause the fault handler not to be called in production (yet work in test if I programmatically throw an error)? 2) Is there anything else I can do to try and figure out where the activity is erroring out without actually remote debugging the activity?

Thanks in advance!

1
I feel your pain. Do a find within the SharePoint generated logs for the name of your workflow's assembly. You'll have better luck than trying to catch, and log it to the history list.gn22
thanks Gurdas! Working with our Sharepoint admin it turned out that logging had been disabled for Sharepoint. Once he turned it back on, the history list logging from my activity started working.laurie

1 Answers

0
votes

It turns out that logging was turned off and this was somehow preventing the fault handler from logging to the event history table (or at least, it seems that turning logging back on magically fixed the issue). It also turned out that the production server did not have .NET 3.5 framework installed on it.