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


Anyone who has 'attended' a physical meeting by 'conferencing in' in knows the frustrations & limitations that come from not being in the room. You're the voice in the ceiling & not equally represented in the conversation.

This is no longer acceptable.

Today, we find ourselves facing the “hybrid work paradox.”

Employees are keen to retain flexibility. At the same time, human-to-human collaboration remains important.

To marry the best of both, hone your strategy, spaces, & tech to suit employee needs.

It's the day of the show, y'all!

Join the #PixelMillWebinars this morning at 11am PST for a live panel discussion about what the #digitalworkspace looks like for a #hybrid team, & how #Microsoft365 can empower your users no matter where they're working.


Join the #PixelMillWebinars this Thursday as we welcome key players from @OrchestrySoft, @KieferConsult, and @AP_Mortgage to discuss the hybrid work paradox and how #Microsoft365 can empower your users no matter where they're working.

We've all been itching to get "back to normal," but what does that mean? Are we missing out on valuable lessons learned by trying to return to something that perhaps wasn't working before?

Join us next week for a live panel discussion on the new normal.

Subscribe to PixelMill's

* indicates required

Let's Talk Digital
Workspaces Today

Get In Touch