blog.scoreman.net

Archive for the ‘InfoPath’ Category

InfoPath error after installing SharePoint 2010 Service Pack 2

Tuesday, October 8th, 2013

Interesting discovery yesterday that I thought I should share. After installing SharePoint 2010 Service pack 2 a customer ran into problems with their InfoPath forms. The generic error message was “The custom code in the form cannot be run. This functionality may be deactivated on the server”. Looking in the ULS log there were some more information:

Microsoft.SharePoint.UserCode.SPUserCodeSolutionProxiedException: Could not load type 'Microsoft.SharePoint.Administration.SPService' from assembly 'Microsoft.SharePoint, Version=14.900.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c'.    Server stack trace:     
 at Microsoft.Office.InfoPath.Server.DocumentLifetime.Document.QueryDataOnLoad(DataAdapter documentDataAdapter, DataObject documentDataObject)    
 at Microsoft.Office.InfoPath.Server.DocumentLifetime.Document.ExecuteInitOnLoadForDataObjects()    
 at Microsoft.Office.InfoPath.Server.DocumentLifetime.Document.LoadFromRemoteContext(Boolean firstOpened, String editingSessionId, Solution solution, Byte[] serializedState, Byte[] serializedVersionState, Dictionary`2 inputParams, OpenParameters openParameters)

After a lot of trial and errors I did some reflection on the Microsoft.Office.InfoPath.Server.DocumentLifetime.Document.QueryDataOnLoad method in Microsoft.Office.InfoPath.Server.dll. The method had a small code change between the Cumulative Update the customer was on and Service Pack 2.

Before Service Pack 2

Before Service Pack 2

After Service Pack 2

After Service Pack 2

The small code change, FormsService formsService = FormsService.TryGetLocal(), uses Microsoft.SharePoint.Administration.SPService. The problem occurs when this code is run from within the sandbox process. Then SPService is not available just like the error message said. QueryDataOnLoad gets called if you have an InfoPath form with data connections that loads on startup.

It is really easy to reproduce this bug. Just install SP2, create an InfoPath form with a data connection (that loads a SharePoint list at startup) and also add code-behind for the loading event. Fortunately the line of code causing the problem is removed in August 2013 Cumulative Update.

Debugging ItemAdded when InfoPath has codebehind in sandbox

Wednesday, October 3rd, 2012

 I was working with a customer that had an InfoPath form with code behind running as a sandboxed solution. The forms library also had an event receiver with both ItemAdded and ItemUpdated. We could debug ItemUpdated but not ItemAdded. I finally found that if the form has code behind running as a sandboxed solution you have to attach to the SPUCWorkerProcessProxy.exe process to debug ItemAdded. Even using Attach to All SharePoint Processes in CKSDev won’t do it since the SPUCWorkerProcessProxy.exe process is not attached. ItemUpdated will run in the normal SharePoint process and not in SPUCWorkerProcessProxy.exe.