An Overview of the SharePoint 2010 Sandbox Solution

[Disclaimer: Article content is based on WSS 4.0 beta1. Information provided herein will probably change as we get closer to production release.]

Since Bamboo was a member of the Microsoft Technnology Adoption Program (TAP) for Office 2010, I had an opportunity to test out early builds of the next version of SharePoint earlier this year. Spotlights were shone upon the cool "F5" feature and how the new VS2010 along with SP2010 will make developer's lives easier.  Nevertheless, my own focus remained on the new SharePoint feature known as Sandbox solution.

Sandbox solution is a pretty powerful idea.  Oftentimes I've wanted to try out a Web Part that I'd come across on the Web, or just wanted to test one of our own Bamboo Web Parts, and the only way I could try it out in SharePoint 2007 was by deploying it in my virtual environment. This is mainly required because I need farm admin rights to use STSADM deployment.  With the sandbox feature I can now be a site collection admin and can still deploy the WSP package. This is good news for developers like me, because now I can quickly deploy a Web Part for testing in my MySite site on our company's portal without breaking anything. This should be quick and easy and could simplify the lives of many. At least in theory.
 
All of this may sound good, but may also cause you to think for a second, "can we really trust sources from over the Web?" "WSP" package could lethal if it is not done properly. We could add assemblies to GAC, change web.configs or even change CAS policy. Worst of all, what will happen if a third party Web Part starts consuming resources without beyond bound?
 
These are not unfounded concerns, but fortunately we don't have to worry about it too much.  SharePoint 2010 has already taken steps to run these solutions in a fortified process. The new infrastructure puts some limits on what can be used from SharePoint Object Model, and it also applies stricter code access security (CAS) policy.  To control the resource usage, it even allows a farm admin to set the quota limit to protect servers from bad code.
 
In this and subsequent sections I will use a sample Web Part (what else than the "Hello Web Part"?) to explore the sandbox environment in further detail.

Step 1: Preparing Web Part for sandbox deployment
 
Assuming you know how to work with Web Parts and package them as WSP solutions, I'll just mention one important thing, and that is the Web Part must be derived from System.Web.UI.WebControls.WebPart namespace. This means that our old SharePoint-based Web Part will not work. The environment does not support SharePoint Web Parts at this time. The ramification of this drop is quite significant. Specially, if you have many older Web Parts that you wish to run in a sandbox environment. The custom tool part properties will require changes and the manifest must be of .webpart extension and schema (However, this change does not apply to solutions deployed in a farm environment).
 
Just in case you need some help preparing the Web Part, check out the following sites:

• ASP.NET Web Parts Overview (http://msdn.microsoft.com/en-us/library/hhy9ewf1.aspx)
• Walkthrough: Creating a Basic SharePoint Web Part (http://msdn.microsoft.com/en-us/library/ms452873.aspx)

Create WSP package before moving to the next step.  For example, here is the Hello World WSP file I used for this exercise.
 

Step 2: Deploying as a sandbox solution
 
Deploying in a sandbox environment is much easier than regular STSADM deployment. The WSP package can be managed through the "Solutions" gallery from the site's top level setting area. Not to be confused with Solutions in Central Admin area. In SharePoint 2010, solutions are of two types (the title has changed slightly). The old Solutions are now called Farm Solutions and the newer kind are called User Solutions. The latter are used to manage sandbox deployments.
 
The upload through Site settings is a simple and straightforward process. Following are some screen shots to help you navigate through the different screens to complete the upload.
 

Figure 1: Sandbox upload process in SharePoint 2010

Once the WSP package is loaded successfully, don't forget to "activate" it before using it on a page. Otherwise the Web Part will not show up in the Web Part Gallery and it will take a while before the problem is identified.
 
Getting this far without any problems is a good sign. But we are still not ready to use the Web Part. During my testing I realized that adding a Web Part directly to a page is not a good idea from a practical perspective, though I learned this the hard way. The error reporting is very minimal in the sandbox environment. This needs to be taken care of, otherwise troubleshooting will be very difficult.
 
During testing, many times I would add a Web Part to a page and would get zero response (and sometimes just a one-line message simply saying there is an error in the Web Part). This pushed me to take some unusual steps. I tried to reinstall, restart the WSS service, add the Web Part multiple times, etc., but all without success. Luckily before my exercise loops forever, I resorted to an old trick. Well, two old tricks. First, I set CallStack= true in web.config and second, I previewed my Web Part from the Web Part Gallery to verify that everything was in working order.
 

Figure 2: Enabling CallStack in the web.config to view error details

Figure 3: Using Web Part Gallery to preview "Hello Web Part"

Once I saw the text, "Hello World!", I knew that my Web Part installation had been successful.
 

Step 3: Adding the Web Part on an ASPX page
 
Now we are ready to put the Web Part on a Web page in our site. Before moving forward, make sure to create a Web Part page.

SharePoint 2010 went through major UI changes and the procedure to add a Web Part to a page is no exception.

Following are some screen shots that show how to do that.

Figure 4: Deck of screen shots.  Adding "Hello world!" Web Part to a page

Once a Web Part has been added successfully to a page, you can use the Web Part menu option to change custom properties to create a personalized greeting. 

Congratulations, you got your first Web Part running in a sandbox environment!

Conclusion
 
Sandbox solution is welcome addition to SharePoint 2010 feature list. Now it is possible for site collection admin to add a WSP package in User Solutions area without having to have SharePoint central admin access or permissions. This will greatly simplify evaluation of 3rd party web parts and give more freedom and control to SharePoint site collection admin to configure the environment to best suit their needs.