Sandbox Code and InfoPath

InfoPath allows you to create forms with very sophisticated logic. Some of this can be done using the out of the box features and formulae but there is always the option to write custom code. I would not recommend using InfoPath if vast amounts of custom code are required (if you’re going to write lots of code, you may as well code the whole thing) but you can get a lot of power by having custom-coded form templates that non-developers can add to their forms, or by adding a bit of custom-coded validation to a form designed by an office worker who will be using the forms.

Another of the great strengths of InfoPath 2007 is the ability to publish forms to SharePoint, meaning that you can fill out forms using a browser. This means you only need the InfoPath client for creating the forms, not for completing them.

You just run into problems when you try to combine these two.

If you want to publish an InfoPath 2007 form which contains custom code to Microsoft Office SharePoint Server 2007, you need administrator approval. The form needs to be uploaded in Central Administration by a farm administrator. This allows the IT staff to check the forms and make certain that the code isn’t going to use ridiculous amounts of resources or otherwise break the SharePoint deployment. This is great from the perspective of control but can be irritating if you’re a developer producing these forms but aren’t an administrator.

One of the new features in SharePoint Server 2010 is the ability to have sandboxed code. The idea of sandboxed code is to produce a compromise between the need for control and the flexibility desired by developers. There’s a lot more information on MSDN but, in brief, site collection administrators can publish their own code. This code has access to a restricted part of SharePoint. The farm administrators can choose how much resource to give sandboxed code and monitor that usage. So developers can publish code to SharePoint without needing to be a farm administrator but badly-written code won’t break the SharePoint deployment.

Sandboxing applies to InfoPath forms as well as to code written in Visual Studio. So with SharePoint 2010, a site collection administrator can produce a form in InfoPath which includes custom code and publish it to SharePoint without needing to get the farm administrators involved. This should make it a lot easier to produce and update customised InfoPath solutions.

Comments

• Anonymous
  January 01, 2003
  Good to know that sandboxed is available through InfoPath forms also. Thanks.

• Anonymous
  January 26, 2011
  i would like to know that can we use sandbox solution on sharepoint Web site without using central administration

• Anonymous
  April 28, 2011
  www.fewlines4biju.com/.../points-about-sharepoint-list.html

• Anonymous
  June 30, 2011
  I've been successful in created a Reusable Workflow with an InfoPath form that has a dropdown to a list then calls the 2nd sandboxed solution passing the ID which creates items in a different list. What I'm trying to do is deploy this to a different farm but the Reusable Workflow was not designed to allow this because the Link GUIDs are hardwired. I have investigated using Data Connections but from what I have read they don't provide this type of connectivity. I've also read you can edit these GUID with the List IDs from the deployed farm. I was wondering if you know of a better way to do this?

• Anonymous
  April 28, 2015
  fgdhfg fghd fghfdg

• Anonymous
  April 28, 2015
  mmmmmmmmm