From the Farm to the Sandbox Launched

I recently built a farm based Branding Solution for SharePoint 2010 in Visual Studio 2010. The solution included all of your normal elements, web parts, fields, content types, list definitions and list instances you might expect. Worked great. Then I had to make it work as a sandboxed solution and, well, epic fail. One of the dirty little secrets of SharePoint wsp packages is that SharePoint does not care if the solution was built as a farm solution or a sandbox solution. The only different in Visual Studio is that Visual Studio attempts to help make sure that you do not reference classes, methods and properties that not available in Sandbox solutions, but the wsp package itself is no different for a farm solution or a sandbox solution. But if you want to take a solution built for the farm and make it run with a sandbox, there are countless pitfalls, and some processes will flat out not work.
After trudging through fix after fix I thought it may help others if I created two VS projects, one for the farm and one for the sandbox that create the same structure and output to the browser as well as a general list of gotcha’s when moving a farm solution to a sandbox solution. I decided the best way to present this would be as a multi part series with each part dealing with a specific aspect of common code you may use in a farm solution that doesn’t work in a sandbox environment.
First, the two project package at CodePlex, download that first.
Now my original solution that was the inspiration for this project was scoped to the site (sandbox solutions only allow site and web scoped solutions don’t forget!) and contained a module for the custom master page and custom page layouts, a module for custom Style Library files, a custom content type for the page layouts as well as for a list definition, a list definition for a list a web part will use, content type fields for the content types, a list instance to define the list that a web part will use and finally a custom web part that included custom properties. The sample projects I provided do not deal as much with Branding (Master Pages and Page Layouts) because there are not major issues in a sandbox vs farm solution, rather the sample projects handle Feature Event Receiver and Web Part code issues.
Much of my original solution transferred over without effort including the modules files (master pages, page layouts and style library files), meaning that I did not need to modify the module elements.xml files. The fields, content types, list definition and list instance also did not need any updates. As already mentioned, the primary changes needed to be made in the feature event receiver and the web part .cs file.
Common Theme of Issues
Most issues I ran into were caused because of the general nature and purpose of sandbox solutions, meaning that sandbox solution run in an isolated environment with no access to the file system, or any aspect of the system, server or web application outside of the scope of the site collection itself. Access to classes such as Microsoft.SharePoint.WebPartPages.WebPart, Microsoft.SharePoint.WebControls.SPControl and  Microsoft.SharePoint.WebControls.CssRegistration and  are not allowed in the sandbox. If you are looking for a complete list of what is allowed, check out Microsoft’s list: Visual Studio 2010 is supposed to help you know what is not allowed, but that doesn’t always seem to work well, nor is it really enforced, so you can quickly build your way into a bind.
A quick summary of the common modifications you may have to make when transitioning your farm solution to be sandbox friendly include the following. Please be aware that this is not an exhaustive list, rather issues I saw that are common based on how many SharePoint solutions appear to be commonly built.

Feature Event Receiver

Automatically Check In Files in a SharePoint 2010 Sandbox Feature Event Receiver

An interesting difference between farm and sandbox solutions is that when files are added to a site in a sandboxed solution, they are added to the database, even if set as ghostable, but they are not checked in nor published in publishing has been enabled.

Housekeeping on Deactivation – Removing What You Added

When you deactivate a feature, the process does not automatically remove modules assets or web parts for you. There is a great way to find all assets to remove using the Microsoft.SharePoint.Administration.SPElementDefinitionCollection returned by Microsoft.SharePoint.Administration.SPFeatureDefinition.GetElementDefinitions(CultureInfo.CurrentCulture). But Sandboxes do not allow access to the Microsoft.SharePoint.Administration.SPFeatureDefinition.GetElementDefinitions method, nor to Microsoft.SharePoint.Administration.SPElementDefinitionCollection for that matter.

Web Parts

Use the Proper Web Part Control

By default when you add a web part to your SharePoint farm Solution, it will inherit from the Microsoft.SharePoint.WebControls.WebPart class, but that is not available to us in the sandbox. It must inherit from the System.Web.UI.WebControls.WebParts.WebPart class. That brings with it many other issues, like dealing with custom properties.

Custom Properties in your Web Part

The easiest way that I know to make your own custom properties available in the web part editor panel is to create your own toolpart inherited from Microsoft.SharePoint.WebPartPages.ToolPart, but like many classes in the Microsoft.SharePoint.WebPartPages namespace, ToolPart is not allowed in Sandboxes. Among other reasons this is why Microsoft now recommends that all web parts should inherit from System.Web.UI.WebControls.WebParts.WebPart, and luckily you can created your own ToolPart the inherits from  System.Web.UI.WebControls.WebParts.EditorPart.

CSS Registration

Many web parts might require their own custom CSS, and since it shouldn’t be added inline, you would then add your stylesheet to a module and use CSSRegistration, but check out that class and where it’s found, Microsoft.SharePoint.WebControls.CSSRegistration. Allowed in Sandboxes? Nope.  Great, time for some hacking.

Linking to JavaScript

Similar to css files, your web part may require custom javascript for client side site behavior. The normal way, how about using this.Page.ClientScript.RegisterClientScriptInclude in your Web Part OnInit function? If you check out the documentation you will find that there is nothing inherently wrong with this function, but it doesn’t work, your js file is not loaded. Why? I haven’t found much documentation on this myself (if you find any great resources, please tell me), but what I have gathered is that the Page object we are getting is not the “Real” page object, but rather a shell version. This means that when we attempt to register our script to the this.Page object, it is being registered with a temporary page object made available only to our sandboxed web part. Changes to this page object do not propagate to the actual Page object.


My suggested fixes to the above common issues are all found in From the Farm to the Sandbox for SharePoint 2010 ( two included projects, although detailed explanations to each issue are coming in future articles. As each issue is addressed, I will update this blog post and link the title of each issue to it’s in-depth explanation as to what the problem is, why it’s there, and much more importantly, how to fix it.
Have you run into other issues when moving your farm solution to a sandbox solution? Please tell me so we can share it with others.

One thought on “From the Farm to the Sandbox Launched

  1. […] pitfalls that you may run into or you may want to be aware of. You can learn more about this series here as well as download the CodePlex Project, From the Farm to the Sandbox, which includes the sample […]

Leave a Comment

Your email address will not be published. Required fields are marked *

Enter Code *

Filed Under


Are you preparing to launch a new #SharePoint #intranet?

Don’t spring it on employees out of the blue. First, talk to as many of them as you can.

Planning is just phase one. For all of our tips, watch our recent webinar with @EricOverfield!

Are you preparing to launch a new #SharePoint intranet?

Don’t spring it on employees out of the blue. First, talk to as many of them as you can.

Planning is just phase one. For all of our tips, watch our recent webinar!

It's that time again! Join #Microsoft MVP & Regional Director, @EricOverfield on Thursday, October 28th, at 11:00 AM PST as he walks through #MicrosoftViva’s current state & offerings and what they mean to your #digitalworkspace right now.

It's the final countdown! Join @EricOverfield at 11am PST to learn about common pitfalls and paths to success when moving to #SharePointOnline. You'll walk away with practical tips to use in your organization today!

In today's episode of the #PixelMillWebinars, you'll learn from the experience of a global organization’s path to digital teamwork victory and get to see first-hand how to successfully plan a smooth migration for your team.

Join us at 11am PST!

Subscribe to PixelMill's

* indicates required

Let's Talk Digital
Workspaces Today

Get In Touch