InfoPath error when runtime dlls are wiped

I had an interesting problem the other day. One of the users of an InfoPath solution I had developed suddenly received errors using the InfoPath form on a VMWare instance, but it worked fine on her desktop. The InfoPath form lived in SharePoint, and had Managed Code I had written. Here’s the error.
User Error when DLLs go missing

It turns out, some clever admin restored a VMWare image that didn’t include the SharePoint runtime DLLs, yet the user’s profile contained the template. The solution was to go into InfoPath and remove the InfoPath template. On the next visit to the SharePoint site to fill out the InfoPath form, both the InfoPath form (*.xsn) as well as the SharePoint DLLs were downloaded and all worked.

It turns out the Infopath form template contains all the files needed to activate a solution, in a single file. It can include .html, .xml, .xsd, .xslt, script, and other file types that are necessary to support the functionality of the form.), such as files that define how controls in the form should appear, files for graphics that appear in the form, and programming files that enable custom behaviors in the form.

Here’s how to remove an InfoPath template on a user’s desktop:
How to remove an InfoPath Template

Using the SP2010 Client Object Model in InfoPath managed code

Someone asked me today about using the SharePoint 2010 Client Object Model in Managed Code.  I’ve done this in VSTA (Visual Studio for Tools and Applications) in C#.  It took a bit of experimentation to get it going, here’s how I did it:

I extracted the Client Object Model runtime DLLs from the SharePoint server.  That’s both Microsoft.SharePoint.Client.dll and Microsoft.SharePoint.Client.runtime.dll.  For good measure I also took Microsoft.SharePoint.Client.Runtime.dll.deploy

In my C# (I was using VSTA) as for Managed C# in InfoPath, I:

  1. Added three project references:
    1. System.Core
    2. SharePoint.Client
    3. SharePoint.Client.Runtime
  2. Added Using for SharePoint.Client

 Opened AssemblyInfo.cs to deal with partial trust exception, and added:

using System.Security; //Added to try to resolve the partial trust error: JP
[assembly: AllowPartiallyTrustedCallers]   //Added to try to resolve the partial trust error: JP

 I had to turn the form  from “Automatically determine security level” to “Full Trust”.  This is an InfoPath specific setting, that may affect how this runs as a Farm Solution, and whether it needs a Farm Administrators approval.

 At that point, you can use the Client Object Model.  Getting data is done two different ways:

–          CAML: my native old-style preferred approach for simple queries

–          LINQ: for SQL-like queries; the one catch is you need to use SPMetal to create a runtime Thunk of sorts specific to your target sites/lists

Hope that helps!