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. farmtosandbox.codeplex.com
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: http://msdn.microsoft.com/en-us/library/ee537860.aspx. 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
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.
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.
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.
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.
My suggested fixes to the above common issues are all found in From the Farm to the Sandbox for SharePoint 2010 (farmtosandbox.codeplex.com) 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.