Monday, 15 June 2009
I feared that the IIS Metabase had been corrupted by the Report Server as part of the SQL 2008 installation.
After checking the event logs, the problem was that the SQL Server Service start timed out on boot and so the "Windows SharePoint Services Web Application" also didn't start. SQL Server eventually restarted (after retrying a second time) but "Windows SharePoint Services Web Application" had not.
I simply went to Central Admin-> Operations -> Services On Server and Started the "Windows SharePoint Services Web Application" Service - the sites that disappeared then re-appeared in IIS.
Sunday, 14 June 2009
InvalidOperationException "The event receiver context for Workflow is invalid" Problems with onTaskChanged in a SharePoint Workflow
If your OnTaskChanged activity is failing and your SharePoint ULS logs are showing something like the following:
06/14/2009 16:50:22.30 w3wp.exe (0x1548) 0x0208 Windows SharePoint Services Workflow Infrastructure 72ev Medium Value cannot be null. 06/14/2009 16:50:24.12 w3wp.exe (0x1548) 0x0208 Windows SharePoint Services Workflow Infrastructure 72ev Medium Value cannot be null. 06/14/2009 16:50:24.40 w3wp.exe (0x1548) 0x0208 Windows SharePoint Services Workflow Infrastructure 72er Medium System.InvalidOperationException: The event receiver context for Workflow is invalid. at Microsoft.SharePoint.SPEventReceiverDefinition.ValidContext() at Microsoft.SharePoint.SPEventReceiverDefinition.ValidReceiverFields() at Microsoft.SharePoint.SPEventReceiverDefinition.GetSqlCommandToAddEventReceivers(IList`1 erds) at Microsoft.SharePoint.Workflow.SPWinOESubscriptionService.CommitNewSubscriptions(Transaction txn, IList`1 erds) 06/14/2009 16:50:24.41 w3wp.exe (0x1548) 0x0208 Windows SharePoint Services Workflow Infrastructure 72fe High Error in commiting pending workflow batch items: System.InvalidOperationException: The event receiver context for Workflow is invalid. at Microsoft.SharePoint.SPEventReceiverDefinition.ValidContext() at Microsoft.SharePoint.SPEventReceiverDefinition.ValidReceiverFields() at Microsoft.SharePoint.SPEventReceiverDefinition.GetSqlCommandToAddEventReceivers(IList`1 erds) at Microsoft.SharePoint.Workflow.SPWinOESubscriptionService.CommitNewSubscriptions(Transaction txn, IList`1 erds) at Microsoft.SharePoint.Workflow.SPPendingWorkBatch.ProcessWorkItemBatch(Transaction transaction, Work method, IList`1 workItemBatch) at Microsoft.SharePoint.Workflow.SPPendingWorkBatch.Commit(Transaction transaction, ICollection items) 06/14/2009 16:50:24.47 w3wp.exe (0x1548) 0x0208 Windows SharePoint Services Workflow Infrastructure 88xr Unexpected WinWF Internal Error, terminating workflow Id# 82d5bb47-18c9-4fa1-a730-121984a7b435
Then you have probably done the following:
- Not assigned a Task Id variable to your OnTaskChanged Handler
- Assigned the wrong Task Id variable to the OnTaskChanged Handler.
- A combination of 1 and 2
I had mistakenly bound my OnTask changed handler in a Parallel workflow to a new variable rather than the existing TaskId variable I set during the Create Task Handler (so the Task Ids didn't match, hence the exception).
Wednesday, 10 June 2009
To get around this issue, you can either:
- Move to ASP.NET Pages for your task form
- Use a dropdown instead in your InfoPath form. You can programmatically populate it as described here: http://www.bizsupportonline.net/infopath2007/programmatically-fill-populate-drop-down-list-box-infopath-2007.htm
Tuesday, 9 June 2009
Looking at the SharePoint Logs in the 12 Hive (e.g. in "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS"), I found the following "Workflow Infrastructure" error with a severity of "Unexpected":
DehydrateInstance: System.Runtime.Serialization.SerializationException: End of Stream encountered before parsing was completed.
The following blog entry on the SharePoint Team Blog
Gave the following possible reasons for a workflow failing in this way:
1. Pitfall: Re-using non-serializable SharePoint objects after rehydrationMany non-workflow specific SharePoint objects, like SPListItem, are not serializable, so when the workflow dehydrates, these items become invalid. So if you try to use them when the workflow wakes up, you will get an error. To avoid this, refetch items if you’re using them after a workflow rehydrates.
2. Pitfall: Forgetting to make custom classes serializableWhen creating your own class in a workflow, don’t forget to add the “Serializable” attribute to the class. If you don’t do this and declare a variable of that class in the workflow’s scope, the workflow will fail when it tries to go to sleep and serialize the class. If you notice that the workflow “completes” when it isn’t supposed to, this may be the culprit.
I marked my custom classes with the [Serializable] attribute and the problems all disappeared.
[UPDATE - 9 Jun 2009]
As discussed in this post:
I also had to tag my member variables for any InfoPath Forms schema-generated objects (even though they are private, they are still serialized) with a [System.NonSerialized] flag. I created a wrapper for my form instead:
private InitiationForm _initiationForm = default(InitiationForm);
//Property for all access to the InfoPath form wrapper class
public InitiationForm InitiationForm
if (_initiationForm == null)
XmlSerializer xs = new XmlSerializer(typeof(InitiationForm));
XmlTextReader xtr = new XmlTextReader(new StringReader(workflowProperties.InitiationData));
_initiationForm = (InitiationForm)xs.Deserialize(xtr);
Thursday, 4 June 2009
Fix - "There is an error in XML document (1, 2)" when deserializing an InfoPath 2007 in a SharePoint Workflow
- "There is an error in XML document (1, 2)" And the the Inner Exception is
- <myFields xmlns='http://schemas.microsoft.com/office/infopath/2003/myXSD/2008-01-16T10:47:10'> was not expected.
Then I suggest that you first check the following:
- The root element name of your InfoPath form (by default called "myfields") MUST match the class name of your xsd.exe-generated mapping file.
Otherwise the XmlSerializer will be looking for a root "myfields" (the default name) element in your C# class and it won't be able to map it to the equivalent element in your InfoPath Xml.
In other words, the xsd.exe generated wrapper class name must match the root element name of your InfoPath form.
For reference, I had this issue and it was simply because I renamed the class name of my xsd.exe-generated file (but I didn't rename my root Infopath element) and so the Serializer couldn't map the new class name to the old root element name in my InfoPath form.
2003 infopath office schemas.microsoft.com 2009-06-26T9:44:10:myFields myXSD>
2003 infopath office schemas.microsoft.com myXSD 2008-01-16T10:47:10?:myfields>
Wednesday, 3 June 2009
As per my previous post (http://ddkonline.blogspot.com/2009/02/fix-error-occurred-either-in-outlook-or.html - related to an Outlook issue) you can do this by typing the following at a command prompt:
- At a command prompt, type "net stop sens" and Enter
- Publish your InfoPath form
- Then to restart it, type "net start sens".
InfoPath 2007 Forms using Forms Services in SharePoint 2007 - "This form cannot be opened. It is not workflow enabled."
If you go to Central Administration -> Applications Management -> Manage Form Templates, it will show your form with the Status of Installing on a permanent basis. This will never complete - so what can you do about it?
This is because the real error when uploading your form is hidden so the install of the form never completes. To discover the real error, click on the "Upload Form Template" button. Enter the file name of your Infopath template (xsn) file (typically located at http://myserverurl/_admin/UploadFormTemplate.aspx) and click the "Verify" button. Resolve these issues and the InfoPath form will deploy and install properly.
The issue I had was that:
- I had created a new InfoPath form
- I had published it but had not left the section entitled "If users access the form template from the published location by using a different path, such as a public URL or full network path, enter it below, and then click Next." section BLANK (otherwise it won't work)
- You need to use the published version of the Form template, not the original design.
Fix for Error when deploying workflow to SharePoint 2007 - "Failed to install the workflow template to Microsoft Office SharePoint Server."
Failed to install the workflow template to Microsoft Office SharePoint Server.
Value cannot be null.
Parameter name: uriString
I could actually right click and run a deploy on the solution manually but I could not run in debug. It appears that the problem was caused by my install of WSPBuilder (http://wspbuilder.codeplex.com/) as when I disabled it from startup and resaved my SharePoint workflow project in Visual Studio, the debugger started working. A simple restart of VS 2008 did not fix the issue.